Hi all, czw., 12 wrz 2019 o 16:00 Michał Brzuchalski <michal.brzuchal...@gmail.com> napisał(a):
> Hi internals, > > I'd like to open discussion about RFC: Object Initializer. > > This proposal reduces boilerplate of object instantiation and properties > initialization in case of classes without required constructor arguments as > a single expression with initializer block. > > https://wiki.php.net/rfc/object-initializer > I'll try to refer to comments proposing other solutions which pop up on this thread in one. Suggested solutions which appeared were: * constructor argument promotion * named arguments While I see them useful in general I don't see them efficient in this specific case. They are not competing features and could live together better suited to different situations. Please be the author for such RFC, I'm looking forward to that. This RFC tries to solve a lot of noise caused by constantly repeating $object-> when assigning properties. Please keep in mind that initializing properties through object initializer applies to visible properties and is possible to assign protected or private properties from the class scope as well. Current RFC was meant to reduce boilerplate especially on DTO|Model classes mimicking "structs" or "data classes" empowering all goods from typed properties. I don't see the reasons why many of you consider public properties a bad solution. PHP language has support for public properties and with typed properties, it is possible to ensure valid object state using VO's which are valid all the time, consider Uuid userland implementation no one checks if that's valid UUID, cause it's ensured by VO. Any kind of features like promoting arguments from the constructor or named arguments are fine but not efficient in those cases. Any good practices suggest limiting function|method arguments while the case is where there is a significant amount of properties to be initialized and additionally which don't need any kind of validation due to VO, or simple scalars. There were also some positive appealing comments, especially like feedback from Benjamin Eberlei. > Using the object initializer would leave the object in a fully consistent state: I am asking myself why didn't include it yet in my RFC. Thank you for the suggestion. I decided to add to proposed RFC that using Object Initializer enforce that if a class is instantiated with the Object Initializer, then at end of the instantiation and properties initialization, all visible (depends on initialization scope) properties are initialized, otherwise a RuntimeException is thrown. This could help with bugs where you add a property to the class, but forget to assign it in all cases where the class is instantiated and initialized. This is described under separate section https://wiki.php.net/rfc/object-initializer#restrictions and mentioned in https://wiki.php.net/rfc/object-initializer#introduction > You should add mention how the Reflection API changes. I would assume both ReflectionClass and ReflectionObject get a new method newInstanceFields(array $fields) with the following behavior: > > $reflectionClass = new ReflectionClass(Customer::class); > $customer = $reflectionClass->newInstanceFields(['name' => 'Bert']); > // the same as > $customer = new Customer {name = 'Bert'}; Done. Added in separate section https://wiki.php.net/rfc/object-initializer#reflection To all who considered this RFC missing some benefit, please try to find it in added restriction which likely would help to avoid bugs with uninitialized properties. To all who didn't like the syntax. I can see arguments in favour of the use of "=>" instead of "=" in initializer block syntax, and would like to propose an additional vote which will help to decide which form fits best. Thanks in advance, Michał Brzuchalski
