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]
