> 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 <kont...@beberlei.de> wrote: > > > On Thu, May 12, 2016 at 9:02 PM, Rasmus Schultz <ras...@mindplay.dk> 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 <ocram...@gmail.com> wrote: >> > On 12 May 2016 at 16:29, Benjamin Eberlei <kont...@beberlei.de> wrote: >> > >> >> On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov <dmi...@zend.com> 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/ > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
