On Fri, Jan 25, 2019 at 4:05 AM Nikita Popov <nikita....@gmail.com> wrote: > > On Fri, Jan 25, 2019 at 11:44 AM Nikita Popov <nikita....@gmail.com> wrote: > > > On Wed, Jan 23, 2019 at 1:33 PM Andrey O Gromov <agro...@alfabank.ru> > > wrote: > > > >> Full description > >> https://wiki.php.net/rfc/code_free_constructor > >> Draft realisation > >> https://github.com/php/php-src/compare/master...rjhdby:constructor > >> > >> "Code free" constructor is constructor with only purpose to directly set > >> object properties from received parameters and, optionally, call parent > >> constructor. > >> > >> Main idea is to move such constructor declaration inside class > >> declaration. > >> > >> Simple example: > >> > >> Current syntax > >> class A extends B{ > >> public $prop; > >> > >> public function __construct($prop){ > >> parent::__construct("BlaBla", $prop); > >> $this->prop = $prop; > >> } > >> } > >> > >> Proposed syntax > >> class A($prop) extends B("BlaBla", $prop) { > >> } > >> > >> With respect, Andrey. > > > > > > Two alternatives you might want to consider: > > > > * https://wiki.php.net/rfc/automatic_property_initialization => Proposed > > function public function __construct(int $this->x, int $this->y) {}, which > > avoids the need for explicit property assignments in the ctor. However, the > > property still needs to be declared separately. > > > > * > > https://docs.hhvm.com/hack/other-features/constructor-parameter-promotion > > => Uses public function __construct(public int $x, public int $y) {} to > > declare properties in-line in the constructor. > > > > I think that *if* we want to add some kind of sugar of this type, then I'd > > strongly prefer the syntax used by Hack than the one proposed here. It > > makes a lot more sense to me intuitively, probably because the property > > declarations still looks like normal property declarations, they just occur > > in-line in the ctor. > > > > Nikita > > > > To add to this: While I can totally understand the motivation to avoid the > property/constructor boilerplate (where the property name needs to be > repeated four times), I think that this is really solving the wrong > problem. The problem is the need to have a constructor at all. > > Both this RFC and the two alternatives mentioned above really target the > case of "dumb" constructors that don't really do anything beyond assigning > properties from ctor arguments. I think that that is better solved by > adding a first-class syntax for object construction. I have something > roughly like this in mind: > > class Point { > public int $x; > public int $y; > public int $z; > } > > // (syntax just a dummy) > $origin = new Point { x = 0, y = 0, z = 0 }; > > Where the object initialization syntax ensures that all properties that > don't have defaults are initialized. Especially now that we have typed > properties and it is feasible to have data objects with just public typed > properties, I think that this is the way to avoid ctor boilerplate, rather > than making it simpler to write that boilerplate. > > Nikita
I support this idea, although I think the `=` should be `=>` like arrays, or `:` like JSON. If you have any more complex of a need (such as private variables) then I think you should write the constructor. The reason is that if you have private variables, you need to establish a public API contract. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php