Re: [RFC] Simple Annotations
| From: | Rowan Collins | Date: | Mon, 16 May 2016 17:23:44 +0000 |
| Subject: | Re: [RFC] Simple Annotations | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-93359@lists.php.net to get a copy of this message | ||
On 16/05/2016 14:05, Rasmus Schultz wrote:
> 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() >>
Well, those particular names look quite likely to collide with users' code, though I guess more
obviously reserved names could be used.
More generally, though, neither feels a natural fit, because of the need to specify a value, rather
than a name. On Reflection, what would an instance of class Memoize look like? Could you call
"new Memoize" somewhere else?
If a memoize() function was executed, what value would it return? Since you can only see the
evaluated value, how could you detect the annotation for debugging?
Indeed, if we're interested only in values, not where they come from, are the following all
equivalent, and the mechanics totally unndetectable by Reflection?
<<null>>
<<(function(){return null;})()>>
function foo() { return null; }
<< foo() >>
If the function form doesn't receive any context, its only purpose would be to copy some
runtime global state into the annotation value on first access, which seems like a strange thing to
do.
> I tend to agree with Richard though, that system directives really
> ought to be supported by the language with keywords rather than
> annotations.
That would be one way around it, indeed, so rather than "Future Scope",
you could label "compiler directive" type annotations as "deliberately
out of scope".
Regards,
--
Rowan Collins
[IMSoP]