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


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 wrote:
On 14/05/2016 20:49, Rasmus Schultz wrote:


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.

Rowan Collins

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 13 of 25 | next ›
Discussion Overview
groupphp-internals @
postedMay 13, '16 at 12:11p
activeMay 17, '16 at 6:39p



site design / logo © 2022 Grokbase