FAQ

What happens if you say <<$x>> and then call $reflection->getAttributes() in your eample? what is $x?

That is the problem with immediately evaluating everything non "constant". There is no context.
There's is no context. Annotations should be context-free - that's by design.

There's also no $this, and no self:: or static:: either, because the
annotations are supposed to be context-free. They're meta-data, not
functions - you already have functions, interfaces, abstract methods
etc. for that.

Suppose you don't have an instance of a class yet, and you reflect and
try to get the value of something that requires context - it doesn't
exist yet. Then what? Obtaining the meta-data before you have an
instance is a common use-case, for example when generating schema from
table/column meta-data attached to entities, you don't have an
instance yet - you're inspecting the class, methods and properties,
not an object.

If you insist on putting something in annotations that requires
context, what you should put in there, is an anonymous function - e.g.
a function that expects the consumer to provide the context, such that
you're not dependent on some implied context, instead you're asking
for a specific context. Dependency injection - good stuff. There's an
example of that in my comment below the gist.

Though personally I would never, ever put functionality in an
annotation - it's a huge misunderstanding, in my opinion. If what you
wanted was executable functionality that requires a context, what you
really want is an interface that you can implement. Context requires a
contract.

Just my opinion, of course, and there's nothing stopping you from
using functions if that's your fancy. And it's much safer and
friendlier to readers, and static analysis tools, not to expect a
run-time context to always be established by the consumer.

Either way, the majority use-case is attaching meta-data to
classes/properties/methods - wanting to attach code and evaluate it at
run-time is a marginal use-case. Designing the whole thing for that
first, and sacrificing all the flexibility of the language itself by
inventing an entirely new concept, which is entirely dependent on
run-time interpretation, in my opinion, is just completely backwards,
when you can do something much, much simpler with far more freedom and
options and design-time safety.

On Thu, May 12, 2016 at 9:27 PM, Benjamin Eberlei wrote:

On Thu, May 12, 2016 at 9:02 PM, Rasmus Schultz wrote:

My problem with this PSR is you've created something that strongly
resembles function or constructor calls, but in reality is just
key/value pairs.

Its actually function calls, not constructors calls :-)

That's confusing in itself, but also puts an unnecessary burden on
consumers who have to figure out how to map this apparently
"something" to "something real" - since it really isn't anything other
than pretty syntax for arrays associated with source-code elements.

Did anybody look at my notes here?

https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46

I think this is much simpler and far more flexible - it lets you do
what you're proposing with attributes (by annotating with simple
arrays) and also lets you create annotation classes.

Would anyone care to comment?

What happens if you say <<$x>> and then call $reflection->getAttributes() in
your eample? what is $x?

That is the problem with immediately evaluating everything non "constant".
There is no context.

On Thu, May 12, 2016 at 4:53 PM, Marco Pivetta wrote:
On 12 May 2016 at 16:29, Benjamin Eberlei wrote:
On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov wrote:

Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP
extension,
but it's not going to be the end of the world, if we decided to live
with
doc-comments only.


Thanks. Dmitry.
I voted -1

Reasons: from a Doctrine Annotations maintainer perspective, either
getting
a list (without keys) of strings back or ast\nodes are not enough or
way
too advanced for our use-case. The middle ground is missing where a
<php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
nested array, that means getAttributes() does should not only return
"string" or ast\node as result for each attribute, to there should be a
way
to get arrays back.

Example:

https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

greetings
Benjamin
Urgh, that is indeed quirky, and makes it unusable.

Is that an implementation or a spec issue? I know PHP 5.6+ allows array
constants, but I am not aware of whether that is in the specification.

Indeed, show-stopper here. I'll have to vote "-1" for now, and wait for
a
version that either explicitly contains any constant expression or just
supports arrays as constants.

I'll also need to compile the branch and try it out myself before voting
further: my bad for being hasty.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 27 of 28 | next ›
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 10, '16 at 6:29p
activeMay 16, '16 at 1:49a
posts28
users10
websitephp.net

People

Translate

site design / logo © 2022 Grokbase