Re: [PHP-DEV] [RFC] Object Initializer

  107085
September 14, 2019 08:49 mike@newclarity.net (Mike Schinkel)
> On Sep 13, 2019, at 3:18 AM, Rasmus Schultz <rasmus@mindplay.dk <mailto:rasmus@mindplay.dk>> wrote: >
> 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 > ... > My strong preference over this feature would be named parameters, > ... > 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.
I mostly agree with the first statements, in abstract principle. 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. Let me explain where I see limitations of named parameters: 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", }, }) 2. Local usage: Consider the following construct. I might use this above the top of a loop if I were writing a very add-hoc custom report. (Please note that I embellished by adding types in a manner I would prefer here.) The following example shows anonymous class declared in local scope. The reason we want to initialize a anonymous class is the same reason we wanted anonymous classes in the first place; often a class is just not important enough to assign a name. And since naming is "one of the 2 or 3 hardest things in programming" not having to assign it a name if a name is not needed is a real plus. And this is not a use-case named parameters address, so this is an explicit example of where object initializers are more general purpose than named parameters: $stats = new class { int total => 0, int mean => 0, int average => 0, int median => 0, } I won't elaborate on how this class is used since hopefully that code would be obvious . But I will say that I would use these types of object initializers almost everywhere I previously have used arrays — and where others have used arrays in code I am refactoring. That would reduce most of array use-cases to collections as I would no longer really need them as associative arrays, unless and framework or library required me to use them. If we had the language features to allow us to concisely move locally-declared associative array code to using anonymous class object instances then IDEs would be able to validate proper use of class properties and cut down on an entire class of coding errors. (Yes, theoretically we can already use anonymous classes instead of arrays but declaring the classes and initializing their properties is so tedious that almost nobody ever codes that way in PHP. Or at least none of the code I have ever come across on GitHub or in client's projects.) 3. Passing to subroutines. This is a contrived example, but it is emblematic of code I write daily. The unfortunate aspect is that since I use an array of $args I cannot have my IDE nor PHP validate that I used the proper array keys. (Note that my example has an error; I used 'field' with query() instead of 'fields' as I should have, to illustrate the problem): class Join { public string $table; public string $from; public string $to; } class QueryBuilder { function query(array $args):object[] { if ( ! $this->validate($args) ) { throw new Exception("Dude!"); } $query = $this->build($args); return $this->run($query); } function validate(array $args) { ... } function build(array $args) { ... } function run(string $query ) { ... } } $qb = new QueryBuilder(); $rows = $qb->query(array( field => ['id','name','cost'], table => 'products', where => 'id=' . $productId, )); Now let us take a look at this example using named parameters. Hopefully you can see it is painfully verbose, definitely not DRY, and likely to result in typos or other refactoring errors: class QueryBuilder { function query(string[] $fields, string $table, Join[] $joins, string[] $wheres ):object[] { if ( ! $this->validate($fields, $table, $joins, $wheres ) ) { throw new Exception("Dude!"); } $query = $this->build($fields, $table, $joins, $wheres); return $this->run($query); } function validate(string[] $fields, string $table, Join[] $joins, string[] $wheres ) { ... } function build(string[] $fields, string $table, Join[] $joins, string[] $wheres ) { ... } ... } If we instead use object initializers, it becomes much readable and maintainable, even though the developer may have initially written the query() method by using named parameters: And unlike using an array to contain all the values my IDE, PHP and other tools can validate whether or not I used the correct property names for Query when calling $qb->query(): 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, }); 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. -Mike
  107094
September 14, 2019 20:47 rowan.collins@gmail.com (Rowan Tommins)
On 14/09/2019 09:49, Mike Schinkel wrote:

> 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]