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....@gmail.com> wrote: > On Sat, Jan 12, 2013 at 5:29 PM, Rasmus Schultz <ras...@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 >
