Hi duke, I moved it to rejected in pro of a new proposal. I briefly drafted it here: https://wiki.php.net/rfc/annotations-in-docblock
There's a lot of things to be officially defined, but basic idea is there. I expect to have a chat with interested core devs to see what can be done in this subject and find some common sense. =) Cheers, On Wed, May 11, 2011 at 6:54 PM, dukeofgaming <dukeofgam...@gmail.com> wrote: > > On Wed, May 11, 2011 at 12:29 PM, guilhermebla...@gmail.com > <guilhermebla...@gmail.com> wrote: >> >> Hi Larz, >> >> On Wed, May 11, 2011 at 3:35 AM, Lars Schultz <lars.schu...@toolpark.com> >> wrote: >> > Am 11.05.2011 00:28, schrieb guilhermebla...@gmail.com: >> >> >> >> - Entities with knowledge about its persistence information >> > >> > That must be something I simply have no knowledge about. But isn't it >> > just a >> > theoretical difference, because in practice, the "code" being >> > annotations or >> > PHP-Code is kept within the class, therefore the entity is not separated >> > from its persistence information...but then I don't really understand >> > the >> > problem in the first place;) >> > >> >> I hope you have OO architecture knowledge. >> By having entity implementing an interface/abstract class, you make >> your domain classes depending on persistence package. >> This dependency breaks OO encapsulation of packages. >> >> By having the code (annotations) within the class you just meta >> classify each property/method of your class. >> You probably don't know, but annotations that you use in Doctrine >> follows a standard document usually referred as JPA (or JSR-317), >> second version. >> So, you may be surprised, but any persistence tool that follows this >> document would be able to support this Entity. One good example is how >> ORM package of Doctrine works and you're able to have your Entity >> "schemaless" with almost 0 changes in ODM package (read as CouchDB and >> MongoDB). > > I think part of the problem on the discussion —regarding the acceptance of > the feature— is that annotations are being seen just as a "cute feature", > instead of an architectural advantage to all good PHP code (i.e. OO taking > advantage of design patterns) and its implications. In summary: they are > huge. If simple reflection can tell the developers what the code is, > annotations let them know what it can be in depending on their context (i.e. > behavior is decoupled). >> >> >> - Resources being wasted >> > >> > Now you sound like Rasmus when he talks about his assembly-history. Do >> > you >> > really expect Annotations to perform better than hard-wired php-code? >> > >> >> Yes, and built-in support is WAY faster. > > If I'm not mistaken, the current comment-parsing solutions are so slow that > the annotated classes and methods and attributes *NEED* the metadata to be > cached in separate PHP code in order to function, otherwise it would be > practically impossible to use them in production sites; conversely, if they > were supported natively caching would not be absolutely necessary. Is this > the case?, if so, I think it is a strong use case to be considered for the > RFC. > BTW, why is it rejected in the wiki now?. Is it completely completely > rejected?, or just postponed?... if it is just cataloged as declined for > now, perhaps it will be harder to retake for discussion later if it appears > as declined?. > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
