annotations, vision, goals

I'm sorry, I guess I wasn't real clear on that - I've always known this
feature as a source directive, guess I didn't know that's not really an
established term.

What I'm referring to is much simpler than what you suggested - it's just
an equivalent to the "source" pre-processor directive in for example C:

http://msdn.microsoft.com/en-us/library/b5w2czay(v=vs.80).aspx

In PHP, this would probably be done using the directive keyword:

http://php.net/manual/en/control-structures.declare.php

It might look something like this:

declare(source=foo/bar.zzz#123) {
// ...
}

Any code that throws (or triggers an error) while the directive is active
will report the source of the error as line 123 in the file "foo/bar.zzz" -
it doesn't seem like a big or complicated feature? And it's a well
established idea that works essentially the same in any language that
supports it.

But it would enable pre-processors to accurately report the source of an
error as occurring not in some temporary generated file, but in the
source-file that generated that line.

As said, this is just an example of a much smaller feature that could have
a bigger impact, but cannot be implemented in userland. Not necessarily the
best (or the only) feature that could enable better implementations of
something like annotations - or many other nice patterns that aren't being
done (or done well) in PHP at the moment...

On Sat, Jan 12, 2013 at 5:29 PM, Rasmus Schultz rasmus@mindplay.dkwrote:

I hear a lot of interesting arguments in this big annotation discussion,
and now there's the ongoing vision discussion, which got me thinking.

It is true that there is broad community interest in annotations - part of
the problem here, is that different groups have differing opinions about
precisely what annotations are, how and when they should be used, the
syntax, and a bunch of other things.

To name a similar example, there is also broad community interest in
e-mail
clients - and countless userland implementations. Nobody is pushing for a
standard e-mail client in PHP. Granted, e-mail is a run-time library
feature, not a language feature, but I don't think it's an unfair
comparison, since annotations aren't really so much a language feature
either, if you think about it - much of the discussions revolve around API
issues, and like someone pointed out, you could do metadata in other ways,
without altering the language or parsing docblocks.

I'm not making this point to argue against annotations, but it lead me
back
to another idea that has surfaced in discussions before: a
source-directive
feature.

This sounds like a much smaller feature, which would be much simpler to
define and agree on, and much simpler to implement.

A source-directive would empower the community to define and implement the
syntax, and not only for annotations, but for other features, such as
aspect-oriented programming, which I believe was once proposed as an RFC
(?) and declined, probably for the same reason... it's a feature with too
many variations and opinions, lots of complexity, and it's probably
another
one of those language-features where the discussions end up revolving
around run-time issues more so than language/syntax.

It would be nice if every developer in the world could all agree on
everything. But we can't, we don't, and we're not going to - and that's
not
a bad thing, because it means PHP is open for innovators to find better
ways to do certain things in userland :-)

The big advantage to having something like implemented and maintained in
userland, is that these features can thrive and grow if they turn out to
be
successful - or, if everyone decides in a year or two that annotations
suck, they can stop using them and move on to something else. It also
means
that developers don't need to wait for a year or more for their sysadmin
to
deploy the next minor PHP update that fixes a bug or makes a minor
addition
to that feature.

Perhaps it's time to think about "lower level" language features that
facilitate implementing "borderline" language-features, and enable the
community to write better, more reliable implementations of things like
annotations and AOP, rather than writing it for them?

And perhaps a source-directive isn't the solution in this case, or perhaps
it's only part of the solution - but what I'm saying is, maybe instead of
lumping on more features that do one thing, perhaps it's time to turn
things around, view things in a different light, and try to think about
things on a somewhat more "meta" level? What's are the smallest "building
block" language features that would enable the community to build bigger
features such as annotations in a better way?

I love annotations. But I love my implementation of annotations, I
probably
won't like yours, and that's not necessarily something we should need to
agree upon.

Is it really the responsibility of the language to deliver high-level
features that support patterns?

Or should it deliver simpler features that support the implementation of
those patterns?

Hey Rasmus!

I'm not sure I entirely understood this mail (mainly because I don't quite
get what you mean by "source directive" and Google couldn't tell me
either). Do you mean introducing something like macros to PHP? Or something
like expression trees? I.e. means to add language features from userland?

If so, this suggestion should be a bit more concrete, because there are so
many different ways to do this at varying degrees. Talking about it in
abstract doesn't lead us anywhere here. If you are talking about language
extensibility to a degree where one could implement annotations (as "real"
syntax) in userland, then I don't think this is realistic. There are only
very few languages that allow these kinds of deep manipulations (and those
languages happen to not be used much ^^).

Nikita