Rowan, I'm afraid I don't follow. Why is it a problem to simply add a function or class to the global namespace?
<< new Memoize() >> or maybe a class with factory functions for built-in annotations: << Meta::memoize() >> I tend to agree with Richard though, that system directives really ought to be supported by the language with keywords rather than annotations. Richard, Regarding your point of view: > The problem is that an annotation by definition is just meta-data. Your > proposal however might result in fatal errors from meta-data I agree that annotations are just meta-data. Values. I disagree that we can't permit the use of PHP expressions to generate those values. You can't eliminate problems such as missing classes - and you shouldn't. With the examples in the Attributes RFC, as well as with e.g. Doctrine Annotations, we have the exact same problems, they're just one step removed from the language feature, which only adds complexity and makes it harder to debug these things. The only work-around to an issue such as a missing class, is to complete ignore the annotation - which leads to undefined behavior and scenarios that are even harder to debug. The other big problem with this position, is that it goes more or less directly against what the community wants - the majority of those who use annotations in PHP today, use Doctrine Annotations, and they expect annotations as classes. Source code can contain errors. I don't think there's really any way around that. Even if you wittled down metadata to the absolute minimum - a string, such as what it is in Go code, that string is invariably going to contain something that needs to be parsed or interpreted somehow, somewhere, at some point, and it can lead to errors. In my opinion, it's better to allow those errors to be caught early - for example, being able to catch syntax errors in expressions already at load-time. The attributes RFC is much worse in this regard - you could be lugging around all kinds of dependency errors, missing classes and whatnot, and you'd never know about it until the day you hit one of those annotations. Now instead, you're just stuck having to type out redundant unit-tests to prove that every annotation is valid, when the language could have taken care of that in a much simpler way. The other issue is dependencies. The Attributes RFC will lead to code with all sorts of hidden dependencies - possibly dependencies that you can't even know about, because you can't know how your metadata is going to be interpreted precisely. You can't know which classes your metadata might get mapped to or how. Simple Annotations take care of that, and they force you to e.g. `composer require` the package that provides the annotation classes you're using - this is a good thing. Hiding dependencies makes it really difficult for others to reason about your code. The Attributes RFC will lead to a lot of hidden rules - whereas Simple Annotations are simple and straight-forward, nothing hidden or implicit, your dependencies visible and traceable, which will lead to much better tooling. For example, an IDE or offline code analysis tool would catch syntax errors and missing classes and warn about those right away. I'm sorry, but I think that the idea of meta-data that can't error somehow, somewhere, at some point, is completely unrealistic. And I'd much rather have a simple facility that enables those errors to surface quickly. On Mon, May 16, 2016 at 11:16 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 14/05/2016 20:49, Rasmus Schultz wrote: >> >> Dan, >> >> I've added a note about special annotations to the "future scope" >> section, naming the memoization-annotation as an example. > > > This doesn't really explain how such a feature would fit it into the > proposal. For instance, how can we avoid the syntax clashing with existing > userland issues? Given that annotations in this proposal don't have names, > we can't just reserve all names beginning "__" or "php\". > > Perhaps they would be pseudo-function calls, like <<__memoize()>>? How would > that (or any other undefined function) act if accessed on a version that > didn't have the feature? > > I realise you don't want to define the details, but an idea of what an > annotation targeting the engine would look like would make the > future-proofing clearer. > > Regards, > -- > Rowan Collins > [IMSoP] > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
