Answers inline On Thu, Nov 26, 2015 at 11:58 AM, Chris Riley <t.carn...@gmail.com> wrote:
> > On 26 November 2015 at 16:05, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > >> Ok then. I'll pretend that lack of interest didn't happen many other >> situations (like http://marc.info/?t=144608767800001) and move on. >> >> I don't want to bring the patch up to date/simplify it without a clear >> decision of at least be willing to discuss the patch and not reject by all >> means. >> I'd propose a voting as "Are you ready for Annotations yet?". Every core >> developer understands (and can base their decisions) by looking at the >> complexity of the old patch. >> >> Once voting completes and IF it gets approved, I'll gladly put it up to >> date for consideration and update the RFC. >> >> []s, >> >> On Thu, Nov 26, 2015 at 10:53 AM, Rowan Collins <rowan.coll...@gmail.com> >> wrote: >> >> > guilhermebla...@gmail.com wrote on 26/11/2015 15:14: >> > >> >> I haven't seen any user asking for traits >> >> >> > >> > Just because you didn't see it, doesn't mean it didn't happen. >> > >> > I just did a very quick search on Google for php + mixins, limited to >> 2007 >> > or earlier (long before the current Trait implementation was born), and >> got >> > plenty of results lamenting the lack of support for horizontal reuse in >> PHP. >> > >> > See for yourself: >> > >> https://encrypted.google.com/search?q=php+%22horizontal+reuse%22&safe=active&hl=en&source=lnt&tbs=cdr%3A1%2Ccd_min%3A%2Ccd_max%3A12%2F31%2F2007&tbm=#safe=active&hl=en&tbs=cdr:1%2Ccd_max:12%2F31%2F2007&q=php+mixins >> > >> > It's a common accusation of projects like this that time was spent on X >> > that should have been spent on Y, but that's nearly always a massive >> > over-simplification. >> > >> > Let's not spend too much time worrying if specific people are >> interested - >> > they may just be on holiday, or busy elsewhere, or just not have much to >> > say until someone assembles a few more details about the proposed >> feature. >> > Keep it constructive, lay out how you think the feature should look and >> > why, what questions are still open, and see what's needed to move it >> > forward. >> > >> > >> > Regards, >> > -- >> > Rowan Collins >> > [IMSoP] >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> >> >> -- >> Guilherme Blanco >> MSN: guilhermebla...@hotmail.com >> GTalk: guilhermeblanco >> Toronto - ON/Canada >> > > Given that a lot of userland people have voting rights; I would suspect > that an annotations rfc would pass, provided it met the needs of these > users. As far as docblocks vs native goes - you've convinced me that native > would be best, previously I'd have been more in favour of adding a > getAnnotations method to ReflectionClass/Method/Property, to pull in > annotations from docblocks. > > I'd like to see this goto a new RFC here are some questions though: > > - Can annotations be applied to functions? > Yes, classes, interfaces, traits, methods, properties, functions. Unfortunately we can't apply to namespaces as they don't exist after compile time. > - Class constants? > No, there's no Reflection data structure around them and imposing one would be a serious BC break > - Should annotations be a special type eg annotation Foo{} or just a class? > Annotation classes would be annotated with @Annotation and their corresponding @Target (where they could be applied). > - Do we want to add decorator support at the same time? ( > http://thecodeship.com/patterns/guide-to-python-function-decorators/) > No. Annotations by itself is already a big endeavor and including more stuff would only make it harder to implement/digest/approve. What if Annotation gets approved, but people want decorator out? More work... Nothing prevent us to make a subsequent RFC to support decorators if the first one gets accepted. Regards, -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
