Hi internals!
In one of the discussions (about the "deprecated" keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.
So, I've created an RFC that propose to improve the Reflection extension by
adding the ability to read annotations decorated in the doc-comment.
https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Regards,
Yahav.
Hi there,
It would be great to have such a feature in reflection itself, since it
would speed up parsing by a huge lot.
Anyway, I noticed that the proposed syntax is quite different from the one
adopted by Doctrine\Common (therefore by Drupal, Symfony, Typo3, ZF, etc.),
which would probably make it a bit hard to migrate for existing apps.
If you check the doc comments of
https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Annotations/DocParser.phpyou
will find the EBNF of the currently used implementation.
I'd really love to see this happening!
Marco Pivetta
Hi internals!
In one of the discussions (about the "deprecated" keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection extension by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Regards,
Yahav.
Hi Yahav,
Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar g.b.yahav@gmail.com:
[...]
In one of the discussions (about the "deprecated" keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection extension by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
From what I've seen in various components using annotations, this kind of support wouldn’t be enough. I would much prefer direct mapping of a single annotation on a class including a way to define properties and such. This is how e.g. Doctrine, Symfony, Zend Framework etc. all utilize annotations nowadays.
cu,
Lars
Hi Yahav,
Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar g.b.yahav@gmail.com:
[...]In one of the discussions (about the "deprecated" keyword, to be
specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection extension
by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Hi!
I do agree with you two about the difference between my proposal and the
way that Doctorine and other FW implemented that, and as I've told - its a
first draft of the proposal - the main idea is to get the ability to have
static metadata. I'll implement the actual patch after we'll agree on the
way it should work :).
About Doctorine implementation, firstly - the parser code is... hugh, I
really think that we should do something about that!
However, I don't think that we should make, like their implementation -
ability to create constructors and such, otherwise, it'll look just like
Attributes...
I think that our work is to isolate each annotation so it'll be easy to
access, then, it'll be easy enough to write the code that creates "complex
annotations", such as constructors and so on, in userland.
From what I've seen in various components using annotations, this kind of
support wouldn’t be enough. I would much prefer direct mapping of a single
annotation on a class including a way to define properties and such. This
is how e.g. Doctrine, Symfony, Zend Framework etc. all utilize annotations
nowadays.Can you provide an example?
cu,
Lars
I think that our work is to isolate each annotation so it'll be easy to
access, then, it'll be easy enough to write the code that creates "complex
annotations", such as constructors and so on, in userland.
In fact, there's probably no need (now) to go on and build a full
annotation reader that instantiates classes and does fancy stuff as we
currently do in doctrine/common.
A fast parser is more than enough I suppose. That's our bottleneck (besides
scanning files).
Marco Pivetta
I think that our work is to isolate each annotation so it'll be easy to
access, then, it'll be easy enough to write the code that creates "complex
annotations", such as constructors and so on, in userland.In fact, there's probably no need (now) to go on and build a full
annotation reader that instantiates classes and does fancy stuff as we
currently do in doctrine/common.
A fast parser is more than enough I suppose. That's our bottleneck
(besides scanning files).Marco Pivetta
So the problem is the syntax which is difference?
When wrote this RFC, I just though about basic cases...
Though I agree with you that the main problem is the syntax.
We can extract the entire doc-comment and only isolate between annotations,
so doc-comment like:
/**
- @Route("/")
- @ORM(Key="foo")
- @var string
*/
Will be : array( 'Route("/")' => "", 'ORM(Key="foo")' => "", "var" =>
"string" )
But the question is it really worth it, since you'll probably need to
create some sort of "sub-parser" that uses this isolated annotations array
and apply on them your syntax.
That's being said, if we'll see performance improvements, I really think
that it's a good solution to start with, since because its not an
Attributes, I don't think that we should dictate the syntax for each
application. Each application will get the doc-comment annotation and will
be able to apply on it its own syntax and fancy stuff... I think that it's
the best solution because of BC too.
What do you think?
2013/1/6 Yahav Gindi Bar g.b.yahav@gmail.com
I think that our work is to isolate each annotation so it'll be easy to
access, then, it'll be easy enough to write the code that creates
"complex
annotations", such as constructors and so on, in userland.In fact, there's probably no need (now) to go on and build a full
annotation reader that instantiates classes and does fancy stuff as we
currently do in doctrine/common.
A fast parser is more than enough I suppose. That's our bottleneck
(besides scanning files).Marco Pivetta
So the problem is the syntax which is difference?
When wrote this RFC, I just though about basic cases...Though I agree with you that the main problem is the syntax.
We can extract the entire doc-comment and only isolate between annotations,
so doc-comment like:
/**
- @Route("/")
- @ORM(Key="foo")
- @var string
*/Will be : array( 'Route("/")' => "", 'ORM(Key="foo")' => "", "var" =>
"string" )
But the question is it really worth it, since you'll probably need to
create some sort of "sub-parser" that uses this isolated annotations array
and apply on them your syntax.
As a suggestion, that should cover most (all?) cases: The identifier could
be defined as "between @ and the first non-alphanumeric character" (it
should probably allow some special like "/", or "" to allow namespace-like
annotations). @Route("/") would be array( 'Route' => '("/")'. Now a
secondary parser only needs to take care about ("/"), but for example it
can already directly test, whether or not the annotation exists.
That's being said, if we'll see performance improvements, I really think
that it's a good solution to start with, since because its not an
Attributes, I don't think that we should dictate the syntax for each
application. Each application will get the doc-comment annotation and will
be able to apply on it its own syntax and fancy stuff... I think that it's
the best solution because of BC too.
To throw that in: Multiline-annotations must be taken into account too :)
Regards,
Sebastian
What do you think?
-Clint
2013/1/6 Yahav Gindi Bar g.b.yahav@gmail.com
I think that our work is to isolate each annotation so it'll be easy to
access, then, it'll be easy enough to write the code that creates
"complex
annotations", such as constructors and so on, in userland.In fact, there's probably no need (now) to go on and build a full
annotation reader that instantiates classes and does fancy stuff as we
currently do in doctrine/common.
A fast parser is more than enough I suppose. That's our bottleneck
(besides scanning files).Marco Pivetta
So the problem is the syntax which is difference?
When wrote this RFC, I just though about basic cases...Though I agree with you that the main problem is the syntax.
We can extract the entire doc-comment and only isolate between annotations,
so doc-comment like:
/**
- @Route("/")
- @ORM(Key="foo")
- @var string
*/Will be : array( 'Route("/")' => "", 'ORM(Key="foo")' => "", "var" =>
"string" )
But the question is it really worth it, since you'll probably need to
create some sort of "sub-parser" that uses this isolated annotations array
and apply on them your syntax.As a suggestion, that should cover most (all?) cases: The identifier could
be defined as "between @ and the first non-alphanumeric character" (it
should probably allow some special like "/", or "" to allow namespace-like
annotations). @Route("/") would be array( 'Route' => '("/")'. Now a
secondary parser only needs to take care about ("/"), but for example it
can already directly test, whether or not the annotation exists.That's being said, if we'll see performance improvements, I really think
that it's a good solution to start with, since because its not an
Attributes, I don't think that we should dictate the syntax for each
application. Each application will get the doc-comment annotation and will
be able to apply on it its own syntax and fancy stuff... I think that it's
the best solution because of BC too.To throw that in: Multiline-annotations must be taken into account too :)
Regards,
SebastianWhat do you think?
2013/1/6 Yahav Gindi Bar g.b.yahav@gmail.com
On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta ocramius@gmail.com
wrote:I think that our work is to isolate each annotation so it'll be easy to
access, then, it'll be easy enough to write the code that creates
"complex
annotations", such as constructors and so on, in userland.In fact, there's probably no need (now) to go on and build a full
annotation reader that instantiates classes and does fancy stuff as we
currently do in doctrine/common.
A fast parser is more than enough I suppose. That's our bottleneck
(besides scanning files).Marco Pivetta
So the problem is the syntax which is difference?
When wrote this RFC, I just though about basic cases...Though I agree with you that the main problem is the syntax.
We can extract the entire doc-comment and only isolate between
annotations,
so doc-comment like:
/**
- @Route("/")
- @ORM(Key="foo")
- @var string
*/Will be : array( 'Route("/")' => "", 'ORM(Key="foo")' => "", "var" =>
"string" )
But the question is it really worth it, since you'll probably need to
create some sort of "sub-parser" that uses this isolated annotations
array
and apply on them your syntax.As a suggestion, that should cover most (all?) cases: The identifier could
be defined as "between @ and the first non-alphanumeric character" (it
should probably allow some special like "/", or "" to allow namespace-like
annotations). @Route("/") would be array( 'Route' => '("/")'. Now a
secondary parser only needs to take care about ("/"), but for example it
can already directly test, whether or not the annotation exists.
I've thought about two types of solutions:
- The first one is to add another argument that supplies additional
characters for the annotation key, so for example getAnnotation("name",
"\/!") Wil match any alphanumericlal values and , / and !. From the
moment it'll catch another tag - it'll be the value.
So
@var String
@param2/param2("bar")
Will be array('var' => 'String', 'param2/param2' => '("bar")' );
- The second option, is to built some pre-defined parsing ways, so for
example we can define
REFLECTION_PARSE_DEFAULT which will parse the annotations just with
alphanumerical characters.
REFLECTION_PARSE_FUNCTION which will make the parsing of the parameters in
the brackets so @ORM(Key="foo") Will be parsed to array( 'ORM' => array(
'key' => "foo" ))
and @MaxLength(255) will be parsed to array ('MaxLength' => 255).
What do you think?
That's being said, if we'll see performance improvements, I really think
that it's a good solution to start with, since because its not an
Attributes, I don't think that we should dictate the syntax for each
application. Each application will get the doc-comment annotation and
will
be able to apply on it its own syntax and fancy stuff... I think that
it's
the best solution because of BC too.To throw that in: Multiline-annotations must be taken into account too :)
Sure! :)
To tell the truth, I've implemented this parsing, too, in userland for
documenting application API's, and including it in PHP can make API
(web-services) documentations really easy!
Regards,
SebastianWhat do you think?
So
@var String
@param2/param2("bar")
Will be array('var' => 'String', 'param2/param2' => '("bar")' );
Let's make this clear immediately: an associative array as output is not
useful.
That would make it impossible to nest annotations. For example, something
like following wouldn't work if the output is just arrays:
@MyApp\Acl({
"allow"=@MyApp\Acl\Allow({"john"="read", "joe"="write"}),
"deny"=@OtherApp\Acl\Deny(default="*", log=true)
})
Maybe a silly example, but nested annotations are not that rare :)
Marco Pivetta
Yahav Gindi Bar wrote:
Though I agree with you that the main problem is the syntax.
We can extract the entire doc-comment and only isolate between annotations,
so doc-comment like:
/**
- @Route("/")
- @ORM(Key="foo")
- @var string
*/Will be : array( 'Route("/")' => "", 'ORM(Key="foo")' => "", "var" =>
"string" )
What about repeated keys? i.e:
@param int $a
@param string $b
--
Ryan McCue
<http://ryanmccue.info/
I don't think that we should dictate the syntax for each application.
Each application will get the doc-comment annotation and will be able
to apply on it its own syntax and fancy stuff...
And this is the exact reason why I think it makes no sense to make a
docblock/annotation reader part of PHP's code (or Reflection). It's fairly
trivial to write a specific extension for each framework's syntax in
case their user land implementation isn't fast enough.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Just a thought on this, some other languages support attributes which is similar but could also allow the engine to use them for things. As a quick example (roughly based on what I've seen in c#) but applied to PHP use case:
class a {
[$date(Nullable)]
public function foo(DateTime $date) { ... }
}
-Clint
Hi internals!
In one of the discussions (about the "deprecated" keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection extension by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Regards,
Yahav.
This is attributes. I saw proposal for attributes that was declined.
I think that the language should contain attributes, but because the lack
of them the Annotations, which's currently used by some FW can be a great
addition.
To tell the troth, even if attributes was implemented in PHP, since the
doc-comment is being used in applications, I think that adding annotations
to the Reflection class can be great anyway. It can be handy in case
there's attributes, for example, to create documentation of functions etc.
Just a thought on this, some other languages support attributes which is
similar but could also allow the engine to use them for things. As a quick
example (roughly based on what I've seen in c#) but applied to PHP use case:class a {
[$date(Nullable)]
public function foo(DateTime $date) { ... }
}-Clint
Hi internals!
In one of the discussions (about the "deprecated" keyword, to be
specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection extension
by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Regards,
Yahav.
There is already a similar RFC here :) Maybe it could be good to start
from this one so that we don't have any duplicated RFC ?
https://wiki.php.net/rfc/annotations-in-docblock
Pierrick
Hi internals!
In one of the discussions (about the "deprecated" keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection extension by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Regards,
Yahav.
Dear Yahav,
At phpDocumentor we have been working on formalizing the PHPDoc
Standard for
quite some time now and I would ask you to take a look at that and use
it as
basis for the parsing of DocBlocks.
You can find the document here:
https://github.com/phpDocumentor/phpDocumentor2/blob/develop/docs/PSR.md
This document contains an ABNF of a PHPDoc including descriptions and
tags as
currently used by conventional and modern applications. Do note that
annotations
are explicitly not detailed in this spec; just their global syntax.
This is because
the PHPDoc Standard is agnostic to these constructs.
This document is still an unfinished draft and open for scrutiny by the
community
and stakeholders. It documents the current state of affairs and also
opens up
discussion for future improvements such as Inline DocBlocks.
Please let me know if you have any questions,
Mike van Riel
Lead Developer of phpDocumentor
Hi internals!
In one of the discussions (about the "deprecated" keyword, to be
specific),
it was been said that adding ability to read doc-comment annotation
could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection
extension by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Regards,
Yahav.
Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard for
quite some time now and I would ask you to take a look at that and use it as
basis for the parsing of DocBlocks.
This also forms the basis of many of the IDE in-line help material. Producing
something different then requires that all the IDE's are reworked as well :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard
for
quite some time now and I would ask you to take a look at that and use it
as
basis for the parsing of DocBlocks.This also forms the basis of many of the IDE in-line help material.
Producing something different then requires that all the IDE's are reworked
as well :(
Annotations have nothing to do with user land documentation, please
don't go down this discussion again as it will be of no help for this
topic.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard for
quite some time now and I would ask you to take a look at that and use it as
basis for the parsing of DocBlocks.This also forms the basis of many of the IDE in-line help material.
Producing something different then requires that all the IDE's are reworked
as well :(Annotations have nothing to do with user land documentation, please
don't go down this discussion again as it will be of no help for this
topic.
So scrap https://wiki.php.net/rfc/reflection_doccomment_annotations and
https://wiki.php.net/rfc/annotations-in-docblock as not being a appropriate way
of handling this then! DocBlocks have a well defined format so hijacking them
for other purposes as this thread is proposing is what is not helpful?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Pierre Joye wrote:
Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard
for
quite some time now and I would ask you to take a look at that and use
it as
basis for the parsing of DocBlocks.This also forms the basis of many of the IDE in-line help material.
Producing something different then requires that all the IDE's are
reworked
as well :(Annotations have nothing to do with user land documentation, please
don't go down this discussion again as it will be of no help for this
topic.So scrap https://wiki.php.net/rfc/reflection_doccomment_annotations and
https://wiki.php.net/rfc/annotations-in-docblock as not being a appropriate
way of handling this then! DocBlocks have a well defined format so hijacking
them for other purposes as this thread is proposing is what is not helpful?
It is helpful because it is the only way to do it right now, within
comments. And no, docblocks are not annotation either.
In my humble opinion there is only one clean way to implement them, at
compile time, using the parser. Using SPL (kind of "let put everything
in there because the engine is too complicated (implementation or
politics around it)") is not a good idea either.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Yahav and all,
Hi internals!
In one of the discussions (about the "deprecated" keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection extension by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Regards,
Yahav.
Why does this need to be part of Reflection? Seems a rather odd place for
it IMHO, since it basically hard-codes the functionality into part of the
core that's not trivially extendable (at least $class->getMethods() is hard
to override)...
Instead, what about adding a SPL class to parse the comment. Something like
class SplAnnotationParser {
const PARSE_DEFAULT = 1;
const PARSE_FUNCTION = 2;
public function __construct($rules = self::PARSE_DEFAULT);
/**
* @param string $comment The comment to parse
* @returns array An array of parsed annotations, pursuant to the
ruleset used
public function parseAnnotations($comment);
}
That way, you'd do:
$parser = new SplAnnotationParser(SplAnnotationParser::PARE_FUNCTION);
foreach ($class->getMethods() as $method) {
$annotations = $parser->parseAnnotations($method->getDocComment());
}
It decouples the implementation, and allows for people to polymorphically
substitute different parsers for different needs.
Thoughts?
Anthony
This is what I was going for. Your idea looks better.
Yahav and all,
Hi internals!
In one of the discussions (about the "deprecated" keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection extension by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Regards,
Yahav.Why does this need to be part of Reflection? Seems a rather odd place for
it IMHO, since it basically hard-codes the functionality into part of the
core that's not trivially extendable (at least $class->getMethods() is hard
to override)...Instead, what about adding a SPL class to parse the comment. Something like
class SplAnnotationParser {
const PARSE_DEFAULT = 1;
const PARSE_FUNCTION = 2;
public function __construct($rules = self::PARSE_DEFAULT);/** * @param string $comment The comment to parse * @returns array An array of parsed annotations, pursuant to theruleset used
public function parseAnnotations($comment);
}That way, you'd do:
$parser = new SplAnnotationParser(SplAnnotationParser::PARE_FUNCTION);
foreach ($class->getMethods() as $method) {
$annotations = $parser->parseAnnotations($method->getDocComment());
}It decouples the implementation, and allows for people to polymorphically
substitute different parsers for different needs.Thoughts?
Anthony
Hi!
Why does this need to be part of Reflection? Seems a rather odd place for
it IMHO, since it basically hard-codes the functionality into part of the
Reflection is an odd place for functionality that describes attributes
of classes, methods, properties, etc.? ITYM "natural place" - that's
exactly what Reflection does.
core that's not trivially extendable (at least $class->getMethods() is hard
to override)...
Why you need to override getMethods in Reflection?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Tue, Jan 8, 2013 at 10:17 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
Why does this need to be part of Reflection? Seems a rather odd place for
it IMHO, since it basically hard-codes the functionality into part of theReflection is an odd place for functionality that describes attributes
of classes, methods, properties, etc.? ITYM "natural place" - that's
exactly what Reflection does.
This functionality parses doccomments and doccomments can be obtained
through various ways. Reflection is only one. Docblocks can just as well
come from parsing the files. If this would be tightly bound to the
reflection mechanisms then it would become useless for many applications,
e.g. phpDocumentor et al couldn't use this (if I'm not much mistaken).
Nikita
Hi!
This functionality parses doccomments and doccomments can be obtained
through various ways. Reflection is only one. Docblocks can just as well
come from parsing the files. If this would be tightly bound to the
You can also get functions, classes, etc. from parsing the files. But
from inside PHP you usually do not, you use Reflection.
reflection mechanisms then it would become useless for many
applications, e.g. phpDocumentor et al couldn't use this (if I'm not
much mistaken).
phpDocumentor is using custom PHP parser anyway, so whatever we do in
core is not very relevant for it, at least in its current state.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
Hi internals!
In one of the discussions (about the "deprecated" keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection extension by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
Using docblock for annotations is a hack in userland because there is
no other way to do it nicely using php scripts. That's why I strongly
opposed to implement it this way in core, or in SPL. It has to be part
of the parser and generated at compile time.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
In one of the discussions (about the "deprecated" keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.So, I've created an RFC that propose to improve the Reflection extension by
adding the ability to read annotations decorated in the doc-comment.https://wiki.php.net/rfc/reflection_doccomment_annotations
What is your opinion about this?
This belongs in an extension, just like last time we've discussed
annotations.
Cheers,
Derick
This belongs in an extension, just like last time we've discussed
annotations.
Last time we discussed this area, we discussed almost everything about
docblock and the likes but actual annotation. However I do not get
your reasoning, annotations are part of languages features, how could
it fit in an extension? That makes no sense.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
This belongs in an extension, just like last time we've discussed
annotations.Last time we discussed this area, we discussed almost everything about
docblock and the likes but actual annotation. However I do not get
your reasoning, annotations are part of languages features, how could
it fit in an extension? That makes no sense.I also agree it is core due to its nature.
But also, given the large amount of frameworks that support the use of
annotations and the nature of
hosting providers and extensions, I really think this is a core feature.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://wwwamsterdamphp.nl