On 23/10/2020 16:52, Theodore Brown wrote:
The problem with this is that it results in inconsistent semantics,
where the number of items in an attribute group results in a
different type of value being passed. I.e. if you remove two of the
three attributes from the list, suddenly the code will break since
the `Assert\All` attribute is no longer being passed an array.
That's a fair point. Perhaps nested attributes could *always* be
considered a list?
That may sound odd, but it's actually quite consistent with "normal"
attributes:
#[Foo]
class C {}
var_dump( (new ReflectionClass('C'))->getAttributes() );
Gives an array with one item in it, not an object:
array(1) {
[0]=> object(ReflectionAttribute)#2 (0) { }
}
So similarly:
#[Foo( 42, #[Bar] )
class C {}
var_dump( (new ReflectionClass('C'))->getAttributes()[0]->getArguments() );
Could give an array with one item in it as the argument:
array(2) {
[0] => int(42),
[1] => array(1) {
[0]=> object(ReflectionAttribute)#3 (0) { }
}
}
This actually feels quite intuitive, because we're used to square
brackets representing arrays. The only downside is a slight
inconvenience for cases where you want an argument of exactly one nested
attribute, but I don't know how common that is.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
