Clint, If you switch from [] to <> everything works like a charm. =) Everything was working smoothly on version 2. Version 3 was an attempt to simplify the patch, but removing tons of things that would pop in a few time if patch was accepted.
Cheers, On Wed, Jan 9, 2013 at 3:24 PM, Clint Priest <cpri...@zerocue.com> wrote: > This version of annotations (attributes?) is much more interesting than > the most recent version, but I could see this syntax as being a problem if > it were allowed to apply to plain functions because then the parser would > have difficulty distinguishing from an array. I suppose the same could be > said of applying it to a class. > > In essence though, this prior revision is exactly the kind of thing that I > would be interested in if we could get past the parsing issues... > > > On 1/9/2013 1:57 PM, guilhermebla...@gmail.com wrote: > >> Pierrick, before update v3 of patch, let's first clarify things that need >> to be discussed. >> Rasmus, you have no idea how happy you made me for a gentle comment >> pointing something we should think before propose a patch instead of on >> (sorry for the wording) bitching about the idea. >> >> There're tons of elements that need to be addressed before working on a >> patch. >> The latest annotations RFC is a small subset of what other languages >> support. To a more complete feature-wise, it is required to go to a >> previous revision: >> https://wiki.php.net/rfc/**annotations?rev=1302087566<https://wiki.php.net/rfc/annotations?rev=1302087566> >> >> Some of the elements that needs to be considered: >> >> - Should we support nested annotations? >> >> - How [Foo()] will be different from new Foo()? If they are not different, >> is there an alternative to not bloat lexical parsing? >> >> - How parameters would be injected? Is constructor the only way to inject >> parameters? >> >> - How would we handle optional parameters, like [Foo("bar", null, null, >> "woo")]? >> >> - Suppose you wanna fix the optional arguments by named parameters, like >> [Foo("bar", test="woo")]. Doesn't it diverge with PHP interests of not >> supporting parametrized arguments? Should we modify the former or the >> later? Personally I'm a fan of named parameters. >> >> - How would we deal with inheritance? Should a method, for example, >> inherit >> the same annotations from parent or not? >> >> - Suppose that you define annotations to fix the inheritance problem, how >> would it be? >> >> - How would we cast possible usages of an annotation to only class, method >> or property? Using annotations too? >> >> - How would it be the syntax to declare a new annotation? >> >> - Would it be possible to modify an annotation value using Reflection, for >> example? >> >> - How could it be handled on APC to minimize the performance impact? >> >> >> Let's discuss? Thanks. >> >> >> >> On Wed, Jan 9, 2013 at 2:24 PM, Marco Pivetta <ocram...@gmail.com> wrote: >> >> @Stas we've already come to that, and this is a way to store metadata: >>> the >>> discussion here is just if and how it should get to PHP :) >>> >>> Marco Pivetta >>> >>> http://twitter.com/Ocramius >>> >>> http://ocramius.github.com/ >>> >>> >> >> > -- > -Clint > -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
