Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107094
To: internals@lists.php.net
References: <CABdc3Wpit02=BqvVE85ciw9qo3UYc2LBatOy23yFk5z+quZ2rw@mail.gmail.com>
 <CADqTB_gwv48eGO7tBLQkQ77BqUA0yJL_QG+DrY+nPzneXDTsvA@mail.gmail.com>
 <BD7D8174-FD06-4DD2-9C53-83F5E29D9428@newclarity.net>
 <0275793C-EC66-4693-B74F-B794E6FF0AC6@newclarity.net>
 <B4BB79C3-45D1-4D74-8A70-ADB770E4663A@newclarity.net>
Message-ID: <4c36506a-c110-4b1f-a902-482ba6b8c55e@gmail.com>
Date: Sat, 14 Sep 2019 21:47:51 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <B4BB79C3-45D1-4D74-8A70-ADB770E4663A@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Object Initializer
From: 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]