On Tue, Apr 14, 2020, at 6:00 AM, Benjamin Eberlei wrote:
> Hi everyone,
>
> I have updated the RFC with much of the feedback received here, on Twitter
> and Reddit.
>
> https://wiki.php.net/rfc/attributes_v2
>
> The following changes were made:
>
> - Changed to support the same attribute multiple times on the same
> declaration
> - Added support for attributes on method and function parameters
> - Replaced *PhpAttribute* interface with an attribute instead
> - Distinction between userland and compiler attributes and description
> when each of them gets evaluated/validated
> - Reduce number of examples to shorten RFC a bit and expand the other
> examples instead
> - Introduced validation of compiler attributes at compile time using a C
> callback
> - Offer alternative syntax “@:” using new token T_ATTRIBUTE which will
> be included with a secondary vote
>
> You may have seen me mentioning that I don't want to deviate from the <<>>
> syntax, a topic of heated debate. As Martin helped me tremendously with the
> RFC and patches he earned to propose an alternative (including patch with
> prototype). So we will have a secondary vote on syntax being either
> <<Attribute>> or @:Attribute.
>
> Let us know what you think about the changes.
>
> greetings
> Benjamin
This looks lovely and I look forward to being able to use it!
Questions:
1. Why is exact-match the default for getAttributes(), and "instanceof" an
extra flag? I would expect it to the other way around. The whole point of LSP
is that any subclass is a viable replacement for its parent; if not, You're
Doing It Wrong(tm). It also means that requesting by interface mandates adding
the second parameter or else it will always return nothing. What is the reason
for not making instanceof the default match and offering an EXACT opt-in mode?
2. Regarding sub-annotations, can you still do classes as parameters even if
not as an annotation marker? Eg:
<<Foo(1, "B", Bar('blah'))>>
function foo()
Or is that also a no-go?
3. I see the most common case for attributes being getting the object version.
With the reflection API as currently described, I see two shortcomings.
A) I can't tell if an attribute has a valid object or not before trying to
access it, which would presumably fail spectacularly. I believe we need a way
to know if getObject() is going to return a valid value before trying to call
it. I think this is a hard-requirement.
B) Related, as is getting all attributes as objects looks to be rather clunky.
$attribute_objectgs = array_filter(array_map(function(ReflectionAttribute $r) {
if ($r->getObject()) { // Needs something better here.
return $r->getObject();
}
}, $obj->getAttributes()));
That's gross. :-) Can "get all the attributes that can be formed into objects"
be its own operation? $obj->getAttributeObjects() or some such, that skips
over non-instantiable attributes and instantiates the rest?
This isn't a requirement, but without it I predict virtually everyone using
attributes is going to have to recreate the knot of code above.
Thanks again!
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
