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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
