# Annotation PHP 7 - Thread: https://externals.io/message/78575 - Original archive: https://news-web.php.net/php.internals/78575 - Started by Alex Sky on 2014-11-03T13:56:02+00:00 - Messages: 41 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/78575.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #78575 — Alex Sky — 2014-11-03T13:56:02+00:00 URL: https://externals.io/message/78575#78575 Hello! There are at least three of the RFC for native work with annotations. https://wiki.php.net/rfc/reflection_doccomment_annotations https://wiki.php.net/rfc/annotations-in-docblock https://wiki.php.net/rfc/annotations I would like to know how plans in PHP 7 support annotations in the code? --- ## #78576 — Chris Wright — 2014-11-03T14:11:27+00:00 URL: https://externals.io/message/78575#78576 · In reply to: #78575 > Hello! > > There are at least three of the RFC for native work with annotations. > https://wiki.php.net/rfc/reflection_doccomment_annotations > https://wiki.php.net/rfc/annotations-in-docblock > https://wiki.php.net/rfc/annotations > > I would like to know how plans in PHP 7 support annotations in the code? > There are no current concrete plans and currently nothing being seriously discussed (at least, not publicly; I don't know if anyone has anything in pipeline that they haven't announced yet). The three RFCs you linked above are all basically dead. You are of course welcome to put together a proposal and/or start up a discussion on the subject if it is something you would be prepared to put work into. Thanks, Chris --- ## #78579 — Jonah H. Harris — 2014-11-03T15:24:23+00:00 URL: https://externals.io/message/78575#78579 · In reply to: #78576 > There are no current concrete plans and currently nothing being seriously > discussed (at least, not publicly; I don't know if anyone has anything in > pipeline that they haven't announced yet). The three RFCs you linked above > are all basically dead. > > You are of course welcome to put together a proposal and/or start up a > discussion on the subject if it is something you would be prepared to put > work into. > I, for one, severely dislike annotations. But, that's why there's an RFC process :) -- Jonah H. Harris Blog: http://www.oracle-internals.com/ --- ## #78581 — Pierre Joye — 2014-11-03T16:26:34+00:00 URL: https://externals.io/message/78575#78581 · In reply to: #78579 > > > > > […] seriously > > […] in > > […] above > > […] put > > […] > > I, for one, severely dislike annotations. But, that's why there's an RFC > process :) I tend to think it is not a taste matter anymore. Symfony ecosystem (components, doctrine and co), Zend framework, etc use them. We see requests to work around user land implementation but we keep us away to get native support. Maybe it is time to the jump and get rid of our tastes, like years ago when we discussed which kind of OO we wanted in php. At the end of the day we do what we did not want back then. --- ## #78582 — Stefan Neufeind — 2014-11-03T16:37:03+00:00 URL: https://externals.io/message/78575#78582 · In reply to: #78581 > > > […] > seriously > > […] > in > > […] > above > > […] > put > > […] > > I tend to think it is not a taste matter anymore. Symfony ecosystem > (components, doctrine and co), Zend framework, etc use them. We see > requests to work around user land implementation but we keep us away to get > native support. Maybe it is time to the jump and get rid of our tastes, > like years ago when we discussed which kind of OO we wanted in php. At the > end of the day we do what we did not want back then. The TYPO3-family (TYPO3 CMS, Flow, Neos) also use annotations. So, yes it is used "in the wild" already and is there to stay. We can imho just make it a bit easier to work with (maybe also performance-wise in some cases) etc. Kind regards, Stefan --- ## #78583 — Larry Garfield — 2014-11-03T17:39:03+00:00 URL: https://externals.io/message/78575#78583 · In reply to: #78582 > > > […] > > The TYPO3-family (TYPO3 CMS, Flow, Neos) also use annotations. > So, yes it is used "in the wild" already and is there to stay. We can > imho just make it a bit easier to work with (maybe also performance-wise > in some cases) etc. > > > Kind regards, > Stefan Drupal is now using annotations as well; not for the Symfony code we've inherited, actually, but for some home-grown systems for which we're using Doctrine's annotation library. Having first-class language support for metadata on definitions would be quite helpful, if for no other reason than native syntax checking and code assistance. (And to help people get over the "it's code in comments!!!" problem, which is entirely because we have to put annotations in comments now as a hack due to the lack of native support.) --Larry Garfield --- ## #78600 — Levi Morrison — 2014-11-03T22:49:54+00:00 URL: https://externals.io/message/78575#78600 · In reply to: #78583 > > > […] > > > > Drupal is now using annotations as well; not for the Symfony code we've > inherited, actually, but for some home-grown systems for which we're using > Doctrine's annotation library. > > Having first-class language support for metadata on definitions would be > quite helpful, if for no other reason than native syntax checking and code > assistance. (And to help people get over the "it's code in comments!!!" > problem, which is entirely because we have to put annotations in comments > now as a hack due to the lack of native support.) Whether the annotation is in a comment or not, the idea of changing behavior at runtime based on the annotation is pretty magical. I highly discourage using this type of feature whether it's in a comment or not. I will certainly vote no on any RFC on this subject, as I see it as being significantly more harmful than helpful. --- ## #78605 — S.A.N — 2014-11-03T23:14:55+00:00 URL: https://externals.io/message/78575#78605 · In reply to: #78600 Nothing magical in the annotations no, they very obvious. It gives you the to declare logic and meta data. I do not like annotated in comments, I like the implementation of annotation in C# 2014-11-04 0:49 GMT+02:00 Levi Morrison : > On Mon, Nov 3, 2014 at 10:39 AM, Larry Garfield > wrote: > > […] > wrote: > > […] > wrote: > > […] > anything > > […] > a > > […] > RFC > > […] > using > > […] > code > > […] > > Whether the annotation is in a comment or not, the idea of changing > behavior at runtime based on the annotation is pretty magical. I > highly discourage using this type of feature whether it's in a comment > or not. > > I will certainly vote no on any RFC on this subject, as I see it as > being significantly more harmful than helpful. --- ## #78612 — Pierre Joye — 2014-11-04T07:49:31+00:00 URL: https://externals.io/message/78575#78612 · In reply to: #78600 > Whether the annotation is in a comment or not, the idea of changing > behavior at runtime based on the annotation is pretty magical. I > highly discourage using this type of feature whether it's in a comment > or not. > > I will certainly vote no on any RFC on this subject, as I see it as > being significantly more harmful than helpful. This is exactly what I meant. We have almost all major projects using them but we may consider not adding them natively because we find it magic, ugly, whatever. As I do consider personal tastes important, there are times where we should listen to our users. --- ## #78620 — Stas Malyshev — 2014-11-04T09:21:17+00:00 URL: https://externals.io/message/78575#78620 · In reply to: #78612 Hi! > As I do consider personal tastes important, there are times where we should > listen to our users. It would be nice to take "paving the walkways" approach, but last time we tried, IIRC we've got into something very over-engineered. Maybe if we try again with more restricted scope (i.e. not trying to put a DSL for describing arbitrarily complex data structures into it :) it would be more successful this time. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #78623 — Pierre Joye — 2014-11-04T10:28:47+00:00 URL: https://externals.io/message/78575#78623 · In reply to: #78620 > Hi! > > > […] > > It would be nice to take "paving the walkways" approach, but last time > we tried, IIRC we've got into something very over-engineered. Maybe if > we try again with more restricted scope (i.e. not trying to put a DSL > for describing arbitrarily complex data structures into it :) it would > be more successful this time. All projects mentioned in this thread use: http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html That makes a pretty good base spec. -- Pierre @pierrejoye | http://www.libgd.org --- ## #78626 — Benjamin Eberlei — 2014-11-04T10:54:56+00:00 URL: https://externals.io/message/78575#78626 · In reply to: #78623 > On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev > wrote: > > […] > should > > […] > > All projects mentioned in this thread use: > > http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html > > That makes a pretty good base spec. > Being the author I can say, the doctrine annotations project is way too over-engineered/special-purpose to land in core. I agree with Stas that a much simpler approach is probably realistic. beginning pure speculation here, i see a short array like syntax like: [foo="bar", bar="baz", baz=["key": "value"]] function annotated_fn() {} Maybe even exactly short array syntax: ["foo"="bar", "bar"="baz", "baz"=["key": "value"]] function annotated_fn() {} Then $reflectionFunction->getAnnotations() returns an array. Various PHP/Userland libraries and frameworks can then stick whatever symantic on top that they want. greetings Benjamin > > -- > Pierre > > @pierrejoye | http://www.libgd.org --- ## #78627 — Pierre Joye — 2014-11-04T11:20:16+00:00 URL: https://externals.io/message/78575#78627 · In reply to: #78626 > > > > […] wrote: > > […] should > > […] http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html > > […] > > > Being the author I can say, the doctrine annotations project is way too over-engineered/special-purpose to land in core. > > I agree with Stas that a much simpler approach is probably realistic. > > beginning pure speculation here, i see a short array like syntax like: > > [foo="bar", bar="baz", baz=["key": "value"]] > function annotated_fn() {} > > Maybe even exactly short array syntax: > > ["foo"="bar", "bar"="baz", "baz"=["key": "value"]] > function annotated_fn() {} > > Then $reflectionFunction->getAnnotations() returns an array. Various PHP/Userland libraries and frameworks can then stick whatever symantic on top that they want. Yes, that was what discussed last time too and makes perfectly sense. I only not sure about the syntax. I do not like that one f.e. not really in phase with what exists (doctrine or other languages). Cheers, Pierre --- ## #78628 — Benjamin Eberlei — 2014-11-04T11:46:12+00:00 URL: https://externals.io/message/78575#78628 · In reply to: #78627 > > > > […] > wrote: > > […] > wrote: > > […] > should > > […] > http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html > > […] > over-engineered/special-purpose to land in core. > > […] > PHP/Userland libraries and frameworks can then stick whatever symantic on > top that they want. > > Yes, that was what discussed last time too and makes perfectly sense. > > I only not sure about the syntax. I do not like that one f.e. not really > in phase with what exists (doctrine or other languages). > The problem with this simple approach is namespacing to avoid clashes, any solution to incoperates that introduces lots of complexity like allowing "new Annotation" inside the array definition. However I guess now that for example composer provides namespaces for packages, the community could come up with a convention to namespace by composer package name to allow something like: ["doctrine/orm": ["entity"]] class User { ["doctrine/orm": ["id", "generatedvalue", "column": ["type": "integer"]]] public $id; } The simplicity here is really key. Validation and mapping of this is much easier implemented in userland code. > Cheers, > Pierre --- ## #78631 — Alexander Lisachenko — 2014-11-04T12:27:05+00:00 URL: https://externals.io/message/78575#78631 · In reply to: #78620 Hi! It would be nice to take "paving the walkways" approach, but last time > we tried, IIRC we've got into something very over-engineered. Maybe if > we try again with more restricted scope (i.e. not trying to put a DSL > for describing arbitrarily complex data structures into it :) it would > be more successful this time. > PHP7 has a wonderful parser, maybe it's possible to provide a general syntax for annotations with userland hooks for arbitrary data. This approach can give a tool for framework developers to define a node visitor for annotations. Alternative way is to define simple key-value storage and access it via Reflector->getAnnotations(). I want to put my huge +1 vote on annotations support in the core, because Go! AOP uses annotations a lot for defining metadata and markers in the code and provides an engine for advanced programming patterns and method interception. Doctrine is good library, but this can be better on core level. --- ## #78635 — Marcio Almada — 2014-11-04T13:18:54+00:00 URL: https://externals.io/message/78575#78635 Hi! > PHP7 has a wonderful parser, maybe it's possible to provide a general > syntax for annotations with userland hooks for arbitrary data. This > approach can give a tool for framework developers to define a node visitor > for annotations. Alternative way is to define simple key-value storage and > access it via Reflector->getAnnotations(). I've been maintaining this annotations library https://github.com/marcioAlmada/annotations, it uses json parser as the interpreter for it's DSL to declare annotations. One of the key features is to allow this key-value storage Alexander pointed out. The main focus is to allow annotations to be declared without the need for a concrete class for each annotation though it doesn't impedes that. I'm wondering if it would be a good idea to unite maintainers of userland annotations libraries and grab the good parts of each project so we can have a merged RFC on this subject? Huge +1 for this discussion too. PHPNG seems like a good milestone to have this core annotations. 2014-11-04 9:27 GMT-03:00 Alexander Lisachenko : Hi! > > It would be nice to take "paving the walkways" approach, but last time > > […] > > PHP7 has a wonderful parser, maybe it's possible to provide a general > syntax for annotations with userland hooks for arbitrary data. This > approach can give a tool for framework developers to define a node visitor > for annotations. Alternative way is to define simple key-value storage and > access it via Reflector->getAnnotations(). > > I want to put my huge +1 vote on annotations support in the core, because > Go! AOP uses annotations a lot for defining metadata and markers in the > code and provides an engine for advanced programming patterns and method > interception. Doctrine is good library, but this can be better on core > level. --- ## #78648 — Andrea Faulds — 2014-11-04T16:34:20+00:00 URL: https://externals.io/message/78575#78648 · In reply to: #78626 > > > I agree with Stas that a much simpler approach is probably realistic. > > beginning pure speculation here, i see a short array like syntax like: > > [foo="bar", bar="baz", baz=["key": "value"]] > function annotated_fn() {} > > Maybe even exactly short array syntax: > > ["foo"="bar", "bar"="baz", "baz"=["key": "value"]] > function annotated_fn() {} > > Then $reflectionFunction->getAnnotations() returns an array. Various > PHP/Userland libraries and frameworks can then stick whatever symantic on > top that they want. The approach for annotations that I like best would actually be not annotations, but Python-style decorators. They’re very simple, but very powerful. They would allow you to do annotations, but also add extra functionality to functions. In Python, a decorator is a function (or callable object), and you use one like this: @some_decorator(foo, bar) def myfunc(): # function source code here This is actually syntactic sugar for the following: def myfunc(): # function source code here myfunc = some_decorator(myfunc, foo, bar) Which would be equivalent to the following PHP code: $myfunc = function myfunc() { # function source code here }; $myfunc = some_decorator($myfunc, foo, bar); Basically, Python decorators allow you to explicitly have a function modify a new function before it’s declared. This is pretty useful: If your decorator does nothing, it’s just an annotation. But you can also use it to add functionality. For example, you might make a decorator that does something before and after a function runs. -- Andrea Faulds http://ajf.me/ --- ## #78661 — Stas Malyshev — 2014-11-04T18:17:28+00:00 URL: https://externals.io/message/78575#78661 · In reply to: #78623 Hi! > All projects mentioned in this thread use: > http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html > That makes a pretty good base spec. Reading it, it looks pretty big - strictly typed values, named parameters, default constructors linked to properties, support for enum types, support for typed arrays, separate constant syntax within annotations. These are all features not supported in PHP, and it seems a bit weird to me to have mini-language inside PHP that would support these. And, of course, arbitrary depth recursive annotations, and for some reason separate array syntax using {} and not []. Moreover, there's extensive checking for annotations with exceptions thrown if any of the above doesn't typecheck - I'm not even sure where that would fit in PHP parser. --- ## #78663 — Stas Malyshev — 2014-11-04T18:27:02+00:00 URL: https://externals.io/message/78575#78663 · In reply to: #78648 Hi! > The approach for annotations that I like best would actually be not > annotations, but Python-style decorators. They’re very simple, but > very powerful. They would allow you to do annotations, but also add > extra functionality to functions. For python-style decorators, at least the way they work in Python, we'd need to organize our function tables differently, as Python just replaces the function with another one while decorating, and I'm not sure it'd be as easy to do with PHP. > Which would be equivalent to the following PHP code: > > $myfunc = function myfunc() { # function source code here }; $myfunc > = some_decorator($myfunc, foo, bar); Not really, because functions work differently in Python and in PHP. You can not just replace a function in class's function table with random closure in PHP, at least easily. You'd have to convert all such functions to closures (or something that can be both, maybe) and have the engine be aware that function table now can store closures. And, also, inheritance may get a bit weird there. It would be very powerful, but it may not be very simple to do. Also, it is a major overkill for what annotations are commonly used - attaching a piece of data to an entity. In Python, decorators are very powerful for modifying function behavior (i.e., attaching pre/post conditions to functions or doing some things phpunit does is really easy) but it is too much for just attaching data. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #78664 — Marcio Almada — 2014-11-04T18:30:07+00:00 URL: https://externals.io/message/78575#78664 · In reply to: #78661 > Reading it - http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html - > it looks pretty big - strictly typed values, named > parameters, default constructors linked to properties, support for enum > types, support for typed arrays, separate constant syntax within > annotations. These are all features not supported in PHP, and it seems a > bit weird to me to have mini-language inside PHP that would support > these. And, of course, arbitrary depth recursive annotations, and for > some reason separate array syntax using {} and not []. From my point of view, most of this complexity is accidental. This happened mostly because, of course, we couldn't have parser / runtime errors inside doc comments. Once we have core annotations, oustide of doc comments, mostly of the DSL described in http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html becomes unnecessary. 2014-11-04 15:17 GMT-03:00 Stas Malyshev : > Hi! > > > […] > Reading it, it looks pretty big - strictly typed values, named > parameters, default constructors linked to properties, support for enum > types, support for typed arrays, separate constant syntax within > annotations. These are all features not supported in PHP, and it seems a > bit weird to me to have mini-language inside PHP that would support > these. And, of course, arbitrary depth recursive annotations, and for > some reason separate array syntax using {} and not []. > Moreover, there's extensive checking for annotations with exceptions > thrown if any of the above doesn't typecheck - I'm not even sure where > that would fit in PHP parser. --- ## #78666 — Florian Anderiasch — 2014-11-04T18:33:15+00:00 URL: https://externals.io/message/78575#78666 · In reply to: #78648 > In Python, a decorator is a function (or callable object), and you use one like this: > > @some_decorator(foo, bar) > def myfunc(): > # function source code here I wonder how feasible it would be to add something like this and allow everything that's allowed in a php function/method call as parameters inside the annotation call - kind of like python does it, which seems to be one of the simplest (in usage, not implementation) forms possible. /** * @ORM\Entity * @Table(name="message") */ class User {} becomes something like @ORM\Entity @Table(['name' => 'message']) class User {} with Entity and Table being callables, obviously. Maybe classes, with User being the first argument, but I haven't thought that through. ~Florian --- ## #78671 — Andrea Faulds — 2014-11-04T18:58:15+00:00 URL: https://externals.io/message/78575#78671 · In reply to: #78663 > > > For python-style decorators, at least the way they work in Python, we'd > need to organize our function tables differently, as Python just > replaces the function with another one while decorating, and I'm not > sure it'd be as easy to do with PHP. Are you sure this would be difficult? We could create a closure of the class method (trivial to do), pass it to a userland function upon creating the class (the former is easy, the “upon creating the class” is the issue), and use the closure it returns as the class method. There’d be issue with autoloading to iron out, but I don’t think it’d be a problem. > You'd have to convert all such functions to closures (or something that > can be both, maybe) and have the engine be aware that function table now > can store closures. And, also, inheritance may get a bit weird there. It > would be very powerful, but it may not be very simple to do. A closure is just a normal function, actually. The Closure class just wraps a zend_function and a this pointer. There’s no reason you couldn’t substitute here. I believe you could literally just copy the zend_function across, though there’d obviously be some complications. Not sure about inheritance. > Also, it is a major overkill for what annotations are commonly used - > attaching a piece of data to an entity. In Python, decorators are very > powerful for modifying function behavior (i.e., attaching pre/post > conditions to functions or doing some things phpunit does is really > easy) but it is too much for just attaching data. This is useful for merely attaching data as well (just return the function passed), but it also enables manipulating the function. It could replace some cases of merely attaching data, too, by making the function do something itself, rather than having something else do something if a function has a certain annotation, when calling that function (if that makes any sense). -- Andrea Faulds http://ajf.me/ --- ## #78675 — S.A.N — 2014-11-04T20:03:08+00:00 URL: https://externals.io/message/78575#78675 · In reply to: #78663 If this is difficult, you can do in PHP 7.0 simple realization annotation/facades, in versions 7.x to develop and refine. Most importantly, define the syntax and semantics annotation/facades, for a version of PHP 7.0 Demand in annotation/facades is very high, ~80% of all popular frameworks their use, it is really what you need PHP developers. 2014-11-04 20:27 GMT+02:00 Stas Malyshev : > Hi! > > > […] > > For python-style decorators, at least the way they work in Python, we'd > need to organize our function tables differently, as Python just > replaces the function with another one while decorating, and I'm not > sure it'd be as easy to do with PHP. > > > […] > > Not really, because functions work differently in Python and in PHP. You > can not just replace a function in class's function table with random > closure in PHP, at least easily. > You'd have to convert all such functions to closures (or something that > can be both, maybe) and have the engine be aware that function table now > can store closures. And, also, inheritance may get a bit weird there. It > would be very powerful, but it may not be very simple to do. > > Also, it is a major overkill for what annotations are commonly used - > attaching a piece of data to an entity. In Python, decorators are very > powerful for modifying function behavior (i.e., attaching pre/post > conditions to functions or doing some things phpunit does is really > easy) but it is too much for just attaching data. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ --- ## #78678 — Sean Coates — 2014-11-04T20:11:05+00:00 URL: https://externals.io/message/78575#78678 · In reply to: #78675 > > […] FWIW (and I apologize if this is just adding to the noise), one of the most powerful things about decorators in Python is that the decorator can do different things in different contexts. For example, in the web-app context `@app.task` might cause a function’s execution be deferred, and return quickly so the actual work can be carried out by another process. In a worker context, `@app.task` could be used to define the work that should actually be carried out by the current worker. Reference for those interested in a practical example: http://celery.readthedocs.org/en/latest/userguide/tasks.html S --- ## #78680 — guilhermeblanco@gmail.com — 2014-11-04T20:18:23+00:00 URL: https://externals.io/message/78575#78680 · In reply to: #78671 Hi, As one of the original authors of both Doctrine Annotations and previous RFC of native Annotations in PHP, I can go thoroughly on every specific detail about challenges of design decisions to make. Primarily, I do not see docblocks as the right place to store class' metadata information. Metadata != Comments. This brings the next piece of the puzzle. We have to update lexical and semantical understanding of PHP. Taking Java's approach (@) does not work in PHP, because it conflicts with error supression. Same thing happened for {}. When Pierrick and I wrote the RFC, [] was not supported, so likely it'll break parsing too now, but at that point, we got [] to work. Ultimately, we chose <> to avoid headaches. After that, we entered on how we could semantically validate arguments. We could easily create an array declaration (as Benjamin suggested), but that would become near to impossible for a large system to figure it out where it was the problem, the small made typo. The solution was to instantiate classes (or what we folded during development, a special class type, annotation), because we could validate semantically not only classes, but also properties. We could also implement annotation targets (something can only be used in a method or at the class level). This is a valid thing to consider... more effort to the language means less efforts from end-users (consumers). Bringing annotation targeting, semantical validation was a great addiction to the RFC, because it makes easier to developers find bugs, but it exposed another set of problems (and their solutions): 1- How to instantiate them? We dropped "new" necessity under that scope and used <>. Again, it made more sense to specialize class definition into a new type (annotation), but we kept same implementation for simplicity. 2- How to consume on Reflection? We decided to use it by fetching based on class name. This added the enforcement of only having 1 instance of a class per annotation context. 3- How to partially attribute class properties while others rely on convention over configuration? We had to bring named parameters to fix this. 4- How to deal with nested Annotations? When we dropped "new", it became easy to support them by using <>. Despite any decision, inheritance is also a problem to solve. Should it clear everything out if a method is overwritten? Should a class require redeclaration of everything? This adds complexity and error-prone situations. What if everything gets inherited by default? Well, then we need a way to remove other previously declared items. We came up with the solution to just clear them until we got into further discussion. We had an Override patch that would inherit everything by default and with Override it would clear any previously declared Annotations too based on discussion's result. I hope that gives a but more insight on how RFC Annotations reached that level of maturity. Cheers, > > > […] > > Are you sure this would be difficult? We could create a closure of the > class method (trivial to do), pass it to a userland function upon creating > the class (the former is easy, the “upon creating the class” is the issue), > and use the closure it returns as the class method. There’d be issue with > autoloading to iron out, but I don’t think it’d be a problem. > > > […] > > A closure is just a normal function, actually. The Closure class just > wraps a zend_function and a this pointer. There’s no reason you couldn’t > substitute here. I believe you could literally just copy the zend_function > across, though there’d obviously be some complications. > > Not sure about inheritance. > > > […] > > This is useful for merely attaching data as well (just return the function > passed), but it also enables manipulating the function. It could replace > some cases of merely attaching data, too, by making the function do > something itself, rather than having something else do something if a > function has a certain annotation, when calling that function (if that > makes any sense). > > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > > > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- Next page: https://externals.io/message/78575.md?page=2