Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64902
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_jBfudnZaWr=QeAiDYeJi1DF0FZuND9vk3=FH=nVomkXg@mail.gmail.com>
References: <CADqTB_jBfudnZaWr=QeAiDYeJi1DF0FZuND9vk3=FH=nVomkXg@mail.gmail.com>
Date: Sat, 12 Jan 2013 19:00:22 +0100
Message-ID: <CAF+90c_Z9xg5hSg9K4Ej9ydc5M1u0cs9xXaz6stBQWg6CQggPg@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec54ee29098f00804d31b2ffc
Subject: Re: [PHP-DEV] annotations, vision, goals
From: nikita.ppv@gmail.com (Nikita Popov)

--bcaec54ee29098f00804d31b2ffc
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jan 12, 2013 at 5:29 PM, Rasmus Schultz <rasmus@mindplay.dk> wrote:

> 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

--bcaec54ee29098f00804d31b2ffc--