[RFC] Object Initializer View as Markdown

On Thu, Sep 12, 2019 at 4:00 PM Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

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 appreciate any feedback you all can provide.

Thanks,

Michał Brzuchalski
brzuchal@php.net

Heya,

What's the added benefit of this compared to implementing a constructor?

The part I like is that this can be used to replace stdClass/structured
arrays. Perhaps something like this would nice to have in PHP:

$people = [];

foreach ($peopleFromDatabase as [$id, $username, $name]) {
    $people[] = {
        Uuid id => $id,
        string username => $username,
        string name => $name,
    };
    // and possible automatic assignment:
    $people[] = {Uuid $id, string $username, string $name};
}

Regards,
Lynn van der Berg

Hi Michal,

https://wiki.php.net/rfc/object-initializer

I recently joined this list again after many years away, and a primary reason was to eventually propose an RFC that is almost exactly what you are calling Object Initializers.

So a huge thumbs up on this RFC. Kudos. I wish I had a vote and I would certainly vote for inclusion.

-Mike

I'd like to address the examples - and why I think they don't demonstrate
that this feature is really useful in practice.

There are several examples similar to this one:

class Car
{
public int $yearOfProduction;
public string $vin;
}

This is either lacking a constructor to initialize the properties to the
defined types - or it's lacking nullable type-hints. As it is, this class
doesn't guarantee initialization according to it's own property type
constraints.

Assuming the fields of this entity are required, you would probably prefer
to add a constructor - but then property initializers aren't really useful
anymore. This seems to be the case for most of the examples.

Models often have other constraints besides just the type - in those cases,
your models would likely have private/protected fields and setter-methods
that implement those constraints. The visibility example demonstrates the
use of a static factory method:

class Customer
{
private string $name = '';
protected ?string $email = null;

public static function create(string $name, ?string $email = null): self
{
return new self {
name = $name, // assign private property within the same class
email = $email, // assign protected property within the same class
};
}
}

This may be fine for some use-cases - but many model types are only going
to have one valid way to construct an instance, and constructors are the
idiomatic way to do that. Unfortunately, this language feature works for
the new-statement only, so a desire to use this language feature will drive
architecture.

All in all, I find this feature is useful or applicable only to a few,
select patterns within the language - it isn't general enough.

In my opinion, language features should be as general as possible - a
feature like this "looks nice", being very abbreviated and clean-looking,
and, as I believe the examples in the RFC itself demonstrates, this will
provide the wrong kind of motivation to make what are, effectively,
architectural decisions.

Some models are immutable by design. Those cases don't seem to be well
supported by this feature.

My strong preference over this feature would be named parameters, which can
provide the same abbreviated initializations, but works more consistently
with the language, e.g. for all of the use-cases I cited above.

It works for constructors:

class Car
{
public int $yearOfProduction;
public string $vin;

public function __construct(int $yearOfProduction, string $vin) {
if ($yearOfProduction < 1900 || $yearOfProduction > date("Y")) {
throw new InvalidArgumentException("year of production out of range:
{$yearOfProduction}");
}

$this->yearOfProduction = $yearOfProduction;
$this->vin = $vin;

}
}

$car = new Car({ yearOfProduction = 1975, vin = "12345678"});

It works for static factory-methods:

$car = Car::create({ yearOfProduction = 1975, vin = "12345678"});

It works for models with private/protected fields, classes with accessors,
classes with validations in constructors or factory-methods, and so on.

In other words, it works more generally with all common patterns and
practices - in many ways, it just seems like a better fit for the language.

The common criticism against named parameters, is they create coupling to
parameter-names. Object initializers create coupling to property-names - if
you can live with that, I don't think named parameters or object
initializers are very different in that regard.

The only problem I see with named parameters as an alternative to object
initializers, is in terms of versioning - renaming an argument, today, is
not a breaking change, and now it would be. That could be addressed, for
example, by making named parameters explicit at the declaration site - for
example, use curly braces in the declaration to designate named arguments:

function makeCar({ int $yearOfProduction, string $vin }) {
// ...
}

This way, adding named parameters is not a breaking change - it's an opt-in
feature for those cases where it's useful and meaningful, but it's still
applicable to all the patterns and cases that someone might want to use it
for.

Named parameters is just one possible alternative - I'm just naming it for
practical comparison, to demonstrate how some features may have more
general applications than others.

I'd prefer to see new features that work everywhere, all the time, for
everyone - and for existing code. Rather than adding more features and
syntax for very specific (even relatively rare) use-cases.

On Thu, Sep 12, 2019 at 4:00 PM Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

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 appreciate any feedback you all can provide.

Thanks,

Michał Brzuchalski
brzuchal@php.net

Though this is truly a stylistic complaint, I think it will lead to
harder-to-analyse code.

Currently I have a static analysis tool that can verify (in 99% of cases)
whether all properties of a class have been initialised in the constructor.
This check is even more important in PHP 7.4, where use of a property
without instantiation is a fatal error.

Figuring out which properties have been instantiated in a constructor is
non-trivial, and it's only efficient to do it once per class.

If we adopt this into the language and people use both __construct and
object initializers for a given class, analysis would become much more
tricky.

In order to find the error in this:

abstract class A {
public string $s;
public int $t;
}

class B extends A {
public bool $u;

public function __construct() {
$this->s = "hello";
}
}

$b = new C {
u = true
};

The analyzer needs to understand that the initialisation of B left a
property uninitialised - it warns about it in B's constructor (
https://psalm.dev/r/0e8e40fefc) but I worry that people will start to
dismiss those warnings as false-positives if this pattern becomes popular.

Best wishes,

Matt

On Thu, 12 Sep 2019 at 10:00, Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

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 appreciate any feedback you all can provide.

Thanks,

Michał Brzuchalski
brzuchal@php.net

Hi Michal,

thank you for this RFC. In combination with typed properties an object
initializer syntax becomes highly thought after in my opinion, especially
if you consider classes consisting mostly of typed PUBLIC properties, for
example data transfer objects or view models.

I find this especially important, because it helps with definitions that
otherwise create unitialized variables:

class Customer
{
public DateTime $created;
}

$foo = new Customer();
// $foo->created now unitialized

Using the object initializer would leave the object in a fully consistent
state:

$foo = new Customer{ created=new DateTime('now') }

Two points I want to mention:

1. Currently with typed properties RFC its possible to declare a public
   property as not nullable, but don't assign it. PHP will make it use the new
   "unitialized" state. This is also done to allow unset() properties later to
   allow hooks via __get. But with this new syntax, we could enforce that if a
   class is new'ed with the object initialzer, then at end of the object
   initializer + constructor, all properties are initialized, otherwise
   Exception. 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 new'ed +
   intialized. One problem could be with RuntimeException that this only
   crashes when the code is run, which is often too late, and would rather
   warrant to just proceed and assume the developer knows what they are doing.
   Also since object initialiizer only sets public properties, the check
   should be for all public variables are initialized.

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'};

On Thu, Sep 12, 2019 at 4:01 PM Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

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 appreciate any feedback you all can provide.

Thanks,

Michał Brzuchalski
brzuchal@php.net

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

This reminds me of how Hack/HHVM would initialize object properties from constructor parameters; I remember finding it very appealing.

IIRC, you would provide the property signature as a constructor parameter to trigger the initialization:

class Foo
{
    protected int $bar;

    public function __construct(protected int $bar)
    {
    }

    public function getBar() : int
    {
        return $this->bar;
    }
}

$foo = new Foo(1);
echo $foo->getBar(); // 1

Perhaps something like that is worth adopting here.

--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

Hi all,

czw., 12 wrz 2019 o 16:00 Michał Brzuchalski michal.brzuchalski@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

чт, 12 сент. 2019 г. в 16:00, Michał Brzuchalski <
michal.brzuchalski@gmail.com>:

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 appreciate any feedback you all can provide.

Thanks,

Michał Brzuchalski
brzuchal@php.net

Thank you Michał for the RFC,

I've have been keeping up with the thread and at this point, I do somewhat
agree with people that maybe the RFC should go into V2 version development.
It really seems like the scope of the RFC is just too small for the feature
and it might be a good idea to expand it a bit.

Also, I have this question - is there any performance to be gained here?
Cause right now object hydration is an issue and is somewhat slow. Can it
be optimised?
Also, usually I don't really want properties to be public (aka writeable),
so that means private/protected and I need to use the methods to set the
properties or reflection. I might have missed or don't remember it, but I
don't think I saw a discussion about that use-case. Value object, DTO's -
all have a big use case for it.

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Hi all,

the discussion period was long and discussion I think quite comprehensive.

I'd like to open the RFC up for a voting today at 11:00 UTC. The voting
will take from 11:00 UTC 7th till 11:00 UTC 21st of October 2019.

BR,
Michał Brzuchalski

czw., 12 wrz 2019 o 16:00 Michał Brzuchalski michal.brzuchalski@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 appreciate any feedback you all can provide.

Thanks,

Michał Brzuchalski
brzuchal@php.net

On Sep 13, 2019, at 3:18 AM, Rasmus Schultz <rasmus@mindplay.dk <mailto:
rasmus@mindplay.dk>> wrote:

Assuming the fields of this entity are required, you would probably
prefer
to add a constructor - but then property initializers aren't really
useful
anymore.

I think this is a false dichotomy; I can see benefit to having
initializers in addition to constructors, even for the same classes.

However, Object Initializers might be best when paired with a new magic
method which let us call __init(), and a required modifier for properties.

Using your Customer example, the __init() would be automatically called
after __construct():

class Customer
{
private string $name = '';
required protected ?string $email = null;

public function __construct(string $name, ?string $email = null)
{
$this->name = $name;
$this->email = $email;
}

public function __init()
{
$this->name = ucwords($this->name);
$this->email = sanitize_email($this->email);
}
}

With __init() a developer could separate capturing construct parameters
from initializing required fields, but the required modifier would allow
developers to indicate which properties should be required.

And it might even make sense to throw an error if an object initializer
does not have an __init() method. Requiring __init() would ensure that
classes not designed to work with initializers would never be initialized
without required fields set.

When creating an object using object initialization I think it should just
bypass and only call __init(). PHP could generate an error if any required
fields are not set.

$customer = new Customer{
name => 'mike schinkel',
email => 'mike@newclarity.net mailto:mike@newclarity.net'
}
echo $customer->name; // Prints "Mike Schinkel"

Actually, a required modifier would not be required to implement object
initializers (no pun intended) but it would enable IDEs, PHP and other
tools validate whether or not a required fields has been set.

As an aside, it would be interesting if there were a __validate() magic
method although it might harm performance too much. OTOH, it should not
harm performance unless you actually use it:

public function __validate(string $field):bool
{
switch ($field) {
case 'name':
return !empty( $this->name ) && strlen($this->name) >= 3;
case 'email':
return validate_email($this->email);
}
return true;
}

a desire to use this language feature will drive architecture. ... this
will
provide the wrong kind of motivation to make what are, effectively,
architectural decisions.

The reason I badly want object initializers is to empower architectures
that currently are not possible in PHP. So I see this as a positive.

I see architectures used in other languages that reduce tedium and enhance
reusability that we cannot implement in PHP because of lack of an object
initializer.

But maybe I do not realize what you are seeing? Can you please elaborate
on the architectures you fear will emerge, ideally with examples and
reasons why they should be avoided?

-Mike

Hey Mike,

lazy initialisation is already possible in userland: adding more magic to
the language for a use-case that is already implemented seems problematic
to me.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

But ironically I come to the exact opposite conclusion that your latter statements imply, i.e. that named parameters are not a generalizable enough feature and that object initializers are much more generalizable.

I think that's only true because you've actually proposed a number of
related but different features.

1. Nested structures: Named parameters, assuming they are not shorthand for initializing objects could not support nested parameters, or at least not without a lot of other supporting additions to PHP too.

$car = new Car({
yearOfProduction => 1975,
vin => "12345678",
engine => {
type => "v8",
capacity => "270ci",
},
})

I'm not sure what "nested parameters" could ever mean, other than
initializing additional objects. And if these are additional objects,
then named parameters work just as well in the nested case as in the
non-nested one:

$car = new Car(
yearOfProduction => 1975,
vin => "12345678",
engine => new Engine(
type => "v8",
capacity => "270ci",
),
);

Indeed, since these are named parameters to a function, you could also
use a static factory method in the same place, which special-case
initializer syntax wouldn't allow you to:

$car = new Car(
yearOfProduction => 1975,
vin => "12345678",
engine => Engine::fromSerialNo(
format => 'ISO',
id => '123abc567'
),
);

2. Local usage
   ...
   $stats = new class {
   int total => 0,
   int mean => 0,
   int average => 0,
   int median => 0,
   }

This already works:

$stats = new class {
var int $total = 0;
var int $mean = 0;
var int $average = 0;
var int $median = 0;
};

What doesn't currently work is using variables from lexical scope in the
definition:

$stats = new class {
var int $total = $a + $b;
var int $mean = $c;
var int $average = $d;
var int $median = $e;
};

However, initializer syntax on its own doesn't solve this, because you
wouldn't be able to specify the types for the properties; just combining
existing syntax with initializers would give something like this:

$stats = new class {
var int $total;
var int $mean;
var int $average;
var int $median;
}{
total => $a + $a,
mean => $c,
average => $d,
median => $e
}

You could certainly make the syntax of initializers and anonymous class
definitions similar, but they're not really the same thing.

3. Passing to subroutines. This is a contrived example, but it is emblematic of code I write daily.

class Query {
public string[] $fields;
public string $table;
public Join $join;
public string[] $where;
}
class QueryBuilder {
function query(Query $query):object[] {
if ( ! $this->validate($query) ) {
throw new Exception("Dude!");
}
$query = $this->build($query);
return $this->run($query);
}
function validate(Query $query) {
...
}
function build(Query $query) {
...
}
...
}
$qb = new QueryBuilder();
$rows = $qb->query(Query{
fields => [ 'id', 'name', 'cost' ],
table => 'products',
where => 'id=' . $productId,
});

The QueryBuilder class in this example has not benefited from object
initializers at all; passing the Query object rather than separate
parameters is a refactoring you can (and probably should) do right now.

The Query class, meanwhile, is no different from the previous examples,
and the call would look just the same with named parameters to the
constructor:

$qb = new QueryBuilder();
$rows = $qb->query(new Query(
fields => [ 'id', 'name', 'cost' ],
table => 'products',
where => 'id=' . $productId,
));

As before, the definition of the class itself is simpler, but I think a
short-hand syntax for constructors would be a better compromise than a
syntax that only worked with public properties and parameterless
constructors.

BTW, if I could have everything I want, I would really like following to work too:

$rows = $qb->query({
fields => [ 'id', 'name', 'cost' ],
table => 'products',
where => 'id=' . $productId,
});

Note above I omitted Query{} and just used {} when calling $qb->query() because PHP should be able to see the signature for query() and pass the initialized values to instantiate a Query object instead of a stdClass instance.

This is an interesting additional proposal, which I admit would be
awkward to implement without initializer syntax. One limitation is that
it only works if dependencies are declared as concrete classes not
interfaces - which like public properties is not "wrong" per se, but
limits the scope of the feature.

Conceptually let me ask, How is { yearOfProduction = 1975, vin = "12345678"} really any different from an instance of an anonymous class with the properties yearOfProduction and vin?

Named parameters are (or would be) a way of setting a bunch of
variables; they're not linked as an object of any sort, so I don't think
there's a natural comparison to anonymous classes at all.

we could use something like func_get_args(ARGS_OBJECT) to allow us to capture the grouped parameters as an instance of an object of anonymous class containing properties for each named parameter

This again is an interesting proposal, but completely unrelated to
object initializer syntax.

If I understand it right, the next example relies on the combination of
anonymous class initialisers, named class initialisers, and named
parameters all using the same syntax, with context determining whether
someFunction({bar => 1, baz => 2}) means a) pass two integer parameters;
b) create and pass a single anonymous class instance; or c) create and
pass a single instance of some class. The examples look really neat on
their own, but imagine coming on that syntax in someone else's code and
trying to work out what it was doing.

There's definitely some interesting ideas here, but they're not all part
of one feature, and they all rely on particular ways of structuring your
code.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]