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

Reply via email to