Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64917
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.220.176 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAF+90c_Z9xg5hSg9K4Ej9ydc5M1u0cs9xXaz6stBQWg6CQggPg@mail.gmail.com>
References: <CADqTB_jBfudnZaWr=QeAiDYeJi1DF0FZuND9vk3=FH=nVomkXg@mail.gmail.com>
	<CAF+90c_Z9xg5hSg9K4Ej9ydc5M1u0cs9xXaz6stBQWg6CQggPg@mail.gmail.com>
Date: Sat, 12 Jan 2013 20:51:47 -0500
Message-ID: <CADqTB_h1QhWKD-86V_P1A4E2-kt560sxk-hy7kpfvbgu=rSMtA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf307d056c806d5904d321c5e7
Subject: Re: [PHP-DEV] annotations, vision, goals
From: rasmus@mindplay.dk (Rasmus Schultz)

--20cf307d056c806d5904d321c5e7
Content-Type: text/plain; charset=ISO-8859-1

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 1:00 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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
>

--20cf307d056c806d5904d321c5e7--