Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64895
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.212.45 cause and error)
MIME-Version: 1.0
Date: Sat, 12 Jan 2013 11:29:02 -0500
Message-ID: <CADqTB_jBfudnZaWr=QeAiDYeJi1DF0FZuND9vk3=FH=nVomkXg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b5daf50f2dfa104d319e85f
Subject: annotations, vision, goals
From: rasmus@mindplay.dk (Rasmus Schultz)

--047d7b5daf50f2dfa104d319e85f
Content-Type: text/plain; charset=ISO-8859-1

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?

- Rasmus Schultz

--047d7b5daf50f2dfa104d319e85f--