hi,
During discussion of different ways of implementing "Design by Contract" we
got an idea of using annotations.
BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:
https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotations
HHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2
The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.
There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...
Thanks. Dmitry.
I decided to explain the proposed annotation syntax "in words" to avoid
misunderstanding
annotations ::= { annotation }.
annotation ::= '<' STRING '>' | '<' STRING '(' expr ')' '>'.
where <expr> is regular PHP expression.
Thanks. Dmitry.
hi,
During discussion of different ways of implementing "Design by Contract"
we got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
I decided to explain the proposed annotation syntax "in words" to avoid
misunderstandingannotations ::= { annotation }.
annotation ::= '<' STRING '>' | '<' STRING '(' expr ')' '>'.where <expr> is regular PHP expression.
Why not doc-block annotations? So it can be parse/understand that is
already there (Doctrine annotations for instance).
Thanks. Dmitry.
hi,
During discussion of different ways of implementing "Design by Contract"
we got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
--
César D. Rodas
Open Source developer
+595-983-161124
PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
you already have doc-block. nothing should be done in PHP core, but you
have to parse it yourself.
The goal of annotations is to provide standard and powerful way.
On the other hand standard PHP expression syntax may be not enough for all
cases.
Thanks. Dmitry.
I decided to explain the proposed annotation syntax "in words" to avoid
misunderstandingannotations ::= { annotation }.
annotation ::= '<' STRING '>' | '<' STRING '(' expr ')' '>'.where <expr> is regular PHP expression.
Why not doc-block annotations? So it can be parse/understand that is
already there (Doctrine annotations for instance).Thanks. Dmitry.
hi,
During discussion of different ways of implementing "Design by Contract"
we got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide
a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
--
César D. Rodas
Open Source developer
+595-983-161124
PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
> you already have doc-block. nothing should be done in PHP core, but
> you have to parse it yourself.
> The goal of annotations is to provide standard and powerful way.
> On the other hand standard PHP expression syntax may be not enough for
> all cases.
Agreed on that. I just thought it could be wise parse natively what is
already out there. Anyways adapt our DocBlock annotation parsers to
parse both (native PHP annotations and docblocks) shouldn't be that hard
either.
As far as I see annotations are supposed to be accessed through
reflections right? Or will it do something automatically as in Python?
Cheers,
>
> Thanks. Dmitry.
>
> On Mon, Feb 16, 2015 at 2:22 PM, Cesar Rodas
>
>
>
> > I decided to explain the proposed annotation syntax "in words"
> to avoid
> > misunderstanding
> >
> > annotations ::= { annotation }.
> > annotation ::= '<' STRING '>' | '<' STRING '(' expr ')' '>'.
> >
> > where
> Why not doc-block annotations? So it can be parse/understand that is
> already there (Doctrine annotations for instance).
>
> >
> > Thanks. Dmitry.
> >
> >
> > On Mon, Feb 16, 2015 at 2:07 PM, Dmitry Stogov
> >
> >> hi,
> >>
> >> During discussion of different ways of implementing "Design by
> Contract"
> >> we got an idea of using annotations.
> >>
> >> BTW: annotations are useful by their own and may be used for
> different
> >> purposes. Support for annotations was proposed long time ago:
> >>
> >> https://wiki.php.net/rfc/annotations
> >> https://wiki.php.net/rfc/annotations-in-docblock
> >> https://wiki.php.net/rfc/reflection_doccomment_annotations
> >>
> >> HHVM already implemented similar concept
> >>
> >> http://docs.hhvm.com/manual/en/hack.attributes.php
> >>
> >> I made a quick and dirty PoC that shows how we may implement
> annotations
> >> in PHP7 and how powerful they may be :
> >> https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2
> >>
> >> The test there is self explainable. Of course, annotations just
> provide a
> >> way to add metadata, but doesn't define attribute names or the
> ways they
> >> are going to be used. Only Reflection API to read.
> >>
> >> There are still a lot of technical problems that have to be solved.
> >> Right now, we just need to answer a question - if we like this
> in PHP7?
> >> Thought and opinions are welcome...
> >>
> >> Thanks. Dmitry.
> >>
>
> --
> César D. Rodas
> Open Source developer
> +595-983-161124
> PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
>
>
>
--
César D. Rodas
Open Source developer
+595-983-161124
PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
yes. like it was proposed at
https://wiki.php.net/rfc/reflection_doccomment_annotations#list_of_methods_to_implement
Thanks. Dmitry.
you already have doc-block. nothing should be done in PHP core, but you
have to parse it yourself.
The goal of annotations is to provide standard and powerful way.
On the other hand standard PHP expression syntax may be not enough for
all cases.Agreed on that. I just thought it could be wise parse natively what is
already out there. Anyways adapt our DocBlock annotation parsers to parse
both (native PHP annotations and docblocks) shouldn't be that hard either.As far as I see annotations are supposed to be accessed through
reflections right? Or will it do something automatically as in Python?Cheers,
Thanks. Dmitry.
I decided to explain the proposed annotation syntax "in words" to avoid
misunderstandingannotations ::= { annotation }.
annotation ::= '<' STRING '>' | '<' STRING '(' expr ')' '>'.where <expr> is regular PHP expression.
Why not doc-block annotations? So it can be parse/understand that is
already there (Doctrine annotations for instance).Thanks. Dmitry.
hi,
During discussion of different ways of implementing "Design by
Contract"
we got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement
annotations
in PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just
provide a
way to add metadata, but doesn't define attribute names or the ways
they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
--
César D. Rodas
Open Source developer
+595-983-161124
PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6--
César D. Rodas
Open Source developer
+595-983-161124
PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
> yes. like it was proposed at
> https://wiki.php.net/rfc/reflection_doccomment_annotations#list_of_methods_to_implement
Awesome. I would +1 for sure!
Cheers,
>
> Thanks. Dmitry.
>
> On Mon, Feb 16, 2015 at 2:34 PM, Cesar Rodas
>
>
>
>> you already have doc-block. nothing should be done in PHP core,
>> but you have to parse it yourself.
>> The goal of annotations is to provide standard and powerful way.
>> On the other hand standard PHP expression syntax may be not
>> enough for all cases.
>
> Agreed on that. I just thought it could be wise parse natively
> what is already out there. Anyways adapt our DocBlock annotation
> parsers to parse both (native PHP annotations and docblocks)
> shouldn't be that hard either.
>
> As far as I see annotations are supposed to be accessed through
> reflections right? Or will it do something automatically as in Python?
>
> Cheers,
>
>
>>
>> Thanks. Dmitry.
>>
>> On Mon, Feb 16, 2015 at 2:22 PM, Cesar Rodas
>>
>>
>>
>> > I decided to explain the proposed annotation syntax "in
>> words" to avoid
>> > misunderstanding
>> >
>> > annotations ::= { annotation }.
>> > annotation ::= '<' STRING '>' | '<' STRING '(' expr ')' '>'.
>> >
>> > where
>> Why not doc-block annotations? So it can be parse/understand
>> that is
>> already there (Doctrine annotations for instance).
>>
>> >
>> > Thanks. Dmitry.
>> >
>> >
>> > On Mon, Feb 16, 2015 at 2:07 PM, Dmitry Stogov
>>
>> >
>> >> hi,
>> >>
>> >> During discussion of different ways of implementing
>> "Design by Contract"
>> >> we got an idea of using annotations.
>> >>
>> >> BTW: annotations are useful by their own and may be used
>> for different
>> >> purposes. Support for annotations was proposed long time ago:
>> >>
>> >> https://wiki.php.net/rfc/annotations
>> >> https://wiki.php.net/rfc/annotations-in-docblock
>> >> https://wiki.php.net/rfc/reflection_doccomment_annotations
>> >>
>> >> HHVM already implemented similar concept
>> >>
>> >> http://docs.hhvm.com/manual/en/hack.attributes.php
>> >>
>> >> I made a quick and dirty PoC that shows how we may
>> implement annotations
>> >> in PHP7 and how powerful they may be :
>> >> https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2
>> >>
>> >> The test there is self explainable. Of course, annotations
>> just provide a
>> >> way to add metadata, but doesn't define attribute names or
>> the ways they
>> >> are going to be used. Only Reflection API to read.
>> >>
>> >> There are still a lot of technical problems that have to
>> be solved.
>> >> Right now, we just need to answer a question - if we like
>> this in PHP7?
>> >> Thought and opinions are welcome...
>> >>
>> >> Thanks. Dmitry.
>> >>
>>
>> --
>> César D. Rodas
>> Open Source developer
>> +595-983-161124
>> PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
>>
>>
>>
>
> --
> César D. Rodas
> Open Source developer
> +595-983-161124
> PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
>
>
--
César D. Rodas
Open Source developer
+595-983-161124
PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
2015-02-16 14:19 GMT+03:00 Dmitry Stogov dmitry@zend.com:
annotations ::= { annotation }.
annotation ::= '<' STRING '>' | '<' STRING '(' expr ')' '>'.where <expr> is regular PHP expression.
Hello!
Really like this syntax, actually you steal my thoughts )) I want to call
this metadata, not an annotations. Just key-value storage for any top-level
elements (namespaces, classes, functions, methods, properties, etc).
Value can by anything, acceptable by PHP parser, then it will be possible
to provide an API to get this AST node "as-is" and to add a logic layer on
top of this. (I'm still waiting for the RFC karma)
For annotations, it should be possible to use <ClassName::class>
constant. Additionally, nested metadata should be supported.
Thanks!
Hi Dmitry,
In my mind, annotation syntax was one level lower, dealing with strings of unknown syntax, not PHP expressions. Something like :
'*' <whitespaces> '@' STRING free-string-up-to-eol
This supports :
- @requires $a > 0
But also :
- @statement INSERT INTO ?? VALUES (13, 'Phoenix', 'AZ', 33, 112)
Using Reflection, the application would get an array of (STRING => array of <free-strings-up-to-eol>) in order of appearance and that's all for the annotation layer. Then, the client has the responsibility to interpret the strings the way it wants.
Even if it is a valid PHP expression, getting it as a string is not a problem. DbC, for instance, would get the string, eval() them and error if one of them evaluates to false. Performance must not be a problem with annotations. This is what makes it suitable for DbC or offline metadata.
If we restrict it to a PHP expression, you need to interpret it at compile time, which makes the process more complex. I must admit I don't understand the reason, as the only one I see is performance. And I am totally out of sync with suggestions to include namespaces, nested annotations, or using class constants in expressions. I even feel incomfortable because it's just 'PHP code, but elsewhere'. I don't see the use case.
About the syntax, I'm probably faulty there, but I don't understand why we cannot use doc blocks. That's easy to parse at compile time, the API is easy to define, the parser already parses them, and everyone is already using that. Existing applications like doctrine just miss the API to use it in a cleaner way but it would be 100% compatible. Actually, I saw several people refusing to consider doc blocks as annotations but I was never given the reason why. So, I am just curious.
Anyway, I don't like the OO features people want to add everywhere. They can get strings and inject them to OO, but that's not the role of the annotation layer, IMHO.
I definitely prefer the KISS approach.
Regards
François
On Tue, Feb 17, 2015 at 6:45 AM, François Laupretre francois@php.net
wrote:
Hi Dmitry,
In my mind, annotation syntax was one level lower, dealing with strings of
unknown syntax, not PHP expressions. Something like :'*' <whitespaces> '@' STRING free-string-up-to-eol
This supports :
- @requires $a > 0
Then you will have to parse the expression your self.
But also :
- @statement INSERT INTO ?? VALUES (13, 'Phoenix', 'AZ', 33, 112)
This is not a problem, nobody prohibit quotes.
<SQL("INSERT INTO ?? VALUES (13, 'Phoenix', 'AZ', 33, 112)")>
Using Reflection, the application would get an array of (STRING => array
of <free-strings-up-to-eol>) in order of appearance and that's all for the
annotation layer. Then, the client has the responsibility to interpret the
strings the way it wants.Even if it is a valid PHP expression, getting it as a string is not a
problem. DbC, for instance, would get the string, eval() them and error if
one of them evaluates to false. Performance must not be a problem with
annotations. This is what makes it suitable for DbC or offline metadata.If we restrict it to a PHP expression, you need to interpret it at compile
time, which makes the process more complex. I must admit I don't understand
the reason, as the only one I see is performance. And I am totally out of
sync with suggestions to include namespaces, nested annotations, or using
class constants in expressions. I even feel incomfortable because it's just
'PHP code, but elsewhere'. I don't see the use case.About the syntax, I'm probably faulty there, but I don't understand why we
cannot use doc blocks. That's easy to parse at compile time, the API is
easy to define, the parser already parses them, and everyone is already
using that. Existing applications like doctrine just miss the API to use it
in a cleaner way but it would be 100% compatible. Actually, I saw several
people refusing to consider doc blocks as annotations but I was never given
the reason why. So, I am just curious.
Any one can use doc-block now and later, but php core won't parse
doc-blocks. It's a task for external tools.
Anyway, I don't like the OO features people want to add everywhere. They
can get strings and inject them to OO, but that's not the role of the
annotation layer, IMHO.I definitely prefer the KISS approach.
I'm agree.
Thanks. Dmitry.
Regards
François
HI Dmitry,
Question : in which scope do you evaluate the PHP expression ?
Example :
<DbC.requires($a > 0);>
<DbC.ensures(RETURN > 0);>
function foo($a)
{
...
How can you know from this that the first expression must be evaluated at function entry, that the second one must be interpreted when function exits, let alone the question of RETURN replacement and external switch to authorize/disable DbC evaluations.
Several people rightly stated that expression would be computed at compile time. That's a way to solve the scope question as it practically means that expressions are evaluated in the global scope, but DbC must evaluate its expressions at runtime. Does it mean we should write '<DbC.requires('$a > 0')> ? Not very intuitive but that's probably the only solution.
Something else : I am not sure I understand, but do you intend evaluating annotation expressions everytime you parse the file. Or would you provide a global switch ?
Any one can use doc-block now and later, but php core won't parse doc-blocks. It's a task for external tools.
I understand. Actually, DbC is not the perfect use case for annotations. It would be fine to find a good use case because neither of DbC, AOP, Doctrine, or phpdoc fit so well.
There comes my last question : is it so interesting and mandatory to implement annotations in the core, instead of an extension which would parse doc blocks when needed, and would return bare strings through a reflection-like API ? I know most want to put annotations in the core, but what's the real benefit, if we don't consider performance ? Do we have use cases comparing both approaches ?
The fact that we voluntarily make it incompatible with phpdoc and doctrine 'annotations' saddens me a bit too because people used to the current 'annotation' meaning will have to integrate that a new PHP native 'annotation' feature, totally different from what they've been using for years. And doctrine is not an edge-case. If there are good reasons, why not, but I don't see them yet.
Regards
François
On Tue, Feb 17, 2015 at 4:50 PM, François Laupretre francois@php.net
wrote:
HI Dmitry,
Question : in which scope do you evaluate the PHP expression ?
We don't evaluate expressions. We just store them. Evaluation and/or
modification is a subject for future development.
Example :
<DbC.requires($a > 0);>
<DbC.ensures(RETURN > 0);>function foo($a)
{
...How can you know from this that the first expression must be evaluated at
function entry, that the second one must be interpreted when function
exits, let alone the question of RETURN replacement and external switch
to authorize/disable DbC evaluations.
If we will support such DbC approach, then an additional extension may use
this attributes to insert their code into appropriate places of main
function.
Thanks. Dmitry.
Several people rightly stated that expression would be computed at compile
time. That's a way to solve the scope question as it practically means that
expressions are evaluated in the global scope, but DbC must evaluate its
expressions at runtime. Does it mean we should write '<DbC.requires('$a >
0')> ? Not very intuitive but that's probably the only solution.Something else : I am not sure I understand, but do you intend evaluating
annotation expressions everytime you parse the file. Or would you provide a
global switch ?Any one can use doc-block now and later, but php core won't parse
doc-blocks. It's a task for external tools.I understand. Actually, DbC is not the perfect use case for annotations.
It would be fine to find a good use case because neither of DbC, AOP,
Doctrine, or phpdoc fit so well.There comes my last question : is it so interesting and mandatory to
implement annotations in the core, instead of an extension which would
parse doc blocks when needed, and would return bare strings through a
reflection-like API ? I know most want to put annotations in the core, but
what's the real benefit, if we don't consider performance ? Do we have use
cases comparing both approaches ?The fact that we voluntarily make it incompatible with phpdoc and doctrine
'annotations' saddens me a bit too because people used to the current
'annotation' meaning will have to integrate that a new PHP native
'annotation' feature, totally different from what they've been using for
years. And doctrine is not an edge-case. If there are good reasons, why
not, but I don't see them yet.Regards
François
hi,
During discussion of different ways of implementing "Design by Contract" we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...
oh please yes, yes yes :-) I don't care for the syntax, although this looks
ok.
One question, when does the php expression get evaluated?
Thanks. Dmitry.
the idea to not evaluate non-constant expressions at all, but just keep AST
and provide interface to read it.
PHP extensions should be able to use them as they like. (evaluate or insert
into AST of function(s), etc).
Thanks. Dmitry.
On Mon, Feb 16, 2015 at 2:36 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:
hi,
During discussion of different ways of implementing "Design by Contract"
we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...oh please yes, yes yes :-) I don't care for the syntax, although this
looks ok.One question, when does the php expression get evaluated?
Thanks. Dmitry.
the idea to not evaluate non-constant expressions at all, but just keep
AST and provide interface to read it.
PHP extensions should be able to use them as they like. (evaluate or
insert into AST of function(s), etc).
Ok so this would expose the AST to userland? Because that is not yet done
or? As a userland developer I would prefer having the values evaluated, for
example using the array expresssion syntax in class properties (only
"constants" expressions allowed).
Looking at the PHPT more, there seems to be a typo, requires is used in the
annotation and requres is in the var_dump?
Thanks. Dmitry.
On Mon, Feb 16, 2015 at 2:36 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:hi,
During discussion of different ways of implementing "Design by Contract"
we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...oh please yes, yes yes :-) I don't care for the syntax, although this
looks ok.One question, when does the php expression get evaluated?
Thanks. Dmitry.
yeah, it was a typo, that I fixed in first place, but not in the output
On Mon, Feb 16, 2015 at 2:49 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:
the idea to not evaluate non-constant expressions at all, but just keep
AST and provide interface to read it.
PHP extensions should be able to use them as they like. (evaluate or
insert into AST of function(s), etc).Ok so this would expose the AST to userland? Because that is not yet done
or? As a userland developer I would prefer having the values evaluated, for
example using the array expresssion syntax in class properties (only
"constants" expressions allowed).Looking at the PHPT more, there seems to be a typo, requires is used in
the annotation and requres is in the var_dump?Thanks. Dmitry.
On Mon, Feb 16, 2015 at 2:36 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:hi,
During discussion of different ways of implementing "Design by
Contract" we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement
annotations in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide
a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...oh please yes, yes yes :-) I don't care for the syntax, although this
looks ok.One question, when does the php expression get evaluated?
Thanks. Dmitry.
2015-02-16 14:42 GMT+03:00 Dmitry Stogov dmitry@zend.com:
the idea to not evaluate non-constant expressions at all, but just keep
AST and provide interface to read it.
PHP extensions should be able to use them as they like. (evaluate or
insert into AST of function(s), etc).Thanks. Dmitry.
It's a good decision, userland frameworks, such as Doctrine/Go! AOP/etc
will use this AST nodes and node visitors to provide an extension
mechanism. Strong +1 here for AST nodes.
On Mon, Feb 16, 2015 at 1:10 PM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:
2015-02-16 14:42 GMT+03:00 Dmitry Stogov dmitry@zend.com:
the idea to not evaluate non-constant expressions at all, but just keep
AST and provide interface to read it.
PHP extensions should be able to use them as they like. (evaluate or
insert into AST of function(s), etc).Thanks. Dmitry.
It's a good decision, userland frameworks, such as Doctrine/Go! AOP/etc
will use this AST nodes and node visitors to provide an extension
mechanism. Strong +1 here for AST nodes.
i think its a bit complicated for userland, although i clearly see the
benefit for things like DbC and AOP.
but what is the API of an AST node and how does the visitor look like?
2015-02-16 15:12 GMT+03:00 Benjamin Eberlei kontakt@beberlei.de:
but what is the API of an AST node and how does the visitor look like?
I have a draft for that:
https://gist.github.com/lisachenko/ffcfdec4c46e01864b33 This is extended
version for php-ast extension that I want to propose for PHP.
On Mon, Feb 16, 2015 at 1:14 PM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:
2015-02-16 15:12 GMT+03:00 Benjamin Eberlei kontakt@beberlei.de:
but what is the API of an AST node and how does the visitor look like?
I have a draft for that:
https://gist.github.com/lisachenko/ffcfdec4c46e01864b33 This is extended
version for php-ast extension that I want to propose for PHP.
in dimitris proposal you already get an AST node back but your code is
about registering extensions and processing, both are only remotely related.
My question is how do i evaluate this at runtime? I suppose a function is
necessary like evaluate_ast(...), but that requires passing the context.
many many open questions and as nikic points out this should probably be
delayed to 7.1 because it all should be discussed and specified.
2015-02-16 15:31 GMT+03:00 Benjamin Eberlei kontakt@beberlei.de:
My question is how do i evaluate this at runtime? I suppose a function is
necessary like evaluate_ast(...), but that requires passing the context.
many many open questions and as nikic points out this should probably be
delayed to 7.1 because it all should be discussed and specified.
This will be like pretty simple to parse:
// For scalars:
$attributes = (new ReflectionMethod(some::class, 'method))->getAttributes();
$cacheableNode = $attributes[Cacheable::class] ?? new
Php\Parser\Node(AST_TYPE_VALUE, 50);
$cacheTime = $cacheableNode->value;
// For more complex things, like expressions or constant, runtime
evaluation can be performed.
$codeNode = $attributes[Php\Contract\Requires::class] ?? new
Php\Parser\Node(AST_TYPE_STATEMENT, '$this->value >=0');
$code = (string) $codeNode;
$result = eval($code);
2015-02-16 15:31 GMT+03:00 Benjamin Eberlei kontakt@beberlei.de:
My question is how do i evaluate this at runtime? I suppose a function is
necessary like evaluate_ast(...), but that requires passing the context.
many many open questions and as nikic points out this should probably be
delayed to 7.1 because it all should be discussed and specified.This will be like pretty simple to parse:
// For scalars:
$attributes = (new ReflectionMethod(some::class, 'method))->getAttributes();
$cacheableNode = $attributes[Cacheable::class] ?? new
Php\Parser\Node(AST_TYPE_VALUE, 50);
$cacheTime = $cacheableNode->value;// For more complex things, like expressions or constant, runtime
evaluation can be performed.
$codeNode = $attributes[Php\Contract\Requires::class] ?? new
Php\Parser\Node(AST_TYPE_STATEMENT, '$this->value >=0');
$code = (string) $codeNode;
$result = eval($code);
So, do we have the interpretation/evaluation of the ASP to the userland?
That could good or bad.
Good: It's pretty flexible
Bad: Not so as fast as doing it in C. It's not easy to understand how to
use it (but I'm sure most annotation libraries would do it for you, so
no that bad).
Am I missing something?
--
César D. Rodas
Open Source developer
+595-983-161124
PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
We don't have final design yet. just idea(s) and a question - should we try
to do it for PHP7 or later or not at all.
Thanks. Dmitry.
2015-02-16 15:31 GMT+03:00 Benjamin Eberlei kontakt@beberlei.de:
My question is how do i evaluate this at runtime? I suppose a function
is
necessary like evaluate_ast(...), but that requires passing the
context.
many many open questions and as nikic points out this should probably be
delayed to 7.1 because it all should be discussed and specified.This will be like pretty simple to parse:
// For scalars:
$attributes = (new ReflectionMethod(some::class,
'method))->getAttributes();
$cacheableNode = $attributes[Cacheable::class] ?? new
Php\Parser\Node(AST_TYPE_VALUE, 50);
$cacheTime = $cacheableNode->value;// For more complex things, like expressions or constant, runtime
evaluation can be performed.
$codeNode = $attributes[Php\Contract\Requires::class] ?? new
Php\Parser\Node(AST_TYPE_STATEMENT, '$this->value >=0');
$code = (string) $codeNode;
$result = eval($code);So, do we have the interpretation/evaluation of the ASP to the userland?
That could good or bad.Good: It's pretty flexible
Bad: Not so as fast as doing it in C. It's not easy to understand how to
use it (but I'm sure most annotation libraries would do it for you, so
no that bad).Am I missing something?
--
César D. Rodas
Open Source developer
+595-983-161124
PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
We don't have final design yet. just idea(s) and a question - should we try
to do it for PHP7 or later or not at all.
That is awesome. I would vote for a yes and I'd like it out ASAP (I
would adapt my own annotation parser to read also this annotations). I
don't know however how hard it is to get it out on 7.0 but I'd like to
have it.
Cheers,
Thanks. Dmitry.
2015-02-16 15:31 GMT+03:00 Benjamin Eberlei kontakt@beberlei.de:
My question is how do i evaluate this at runtime? I suppose a function
is
necessary like evaluate_ast(...), but that requires passing the
context.
many many open questions and as nikic points out this should probably be
delayed to 7.1 because it all should be discussed and specified.This will be like pretty simple to parse:
// For scalars:
$attributes = (new ReflectionMethod(some::class,
'method))->getAttributes();
$cacheableNode = $attributes[Cacheable::class] ?? new
Php\Parser\Node(AST_TYPE_VALUE, 50);
$cacheTime = $cacheableNode->value;// For more complex things, like expressions or constant, runtime
evaluation can be performed.
$codeNode = $attributes[Php\Contract\Requires::class] ?? new
Php\Parser\Node(AST_TYPE_STATEMENT, '$this->value >=0');
$code = (string) $codeNode;
$result = eval($code);So, do we have the interpretation/evaluation of the ASP to the userland?
That could good or bad.Good: It's pretty flexible
Bad: Not so as fast as doing it in C. It's not easy to understand how to
use it (but I'm sure most annotation libraries would do it for you, so
no that bad).Am I missing something?
--
César D. Rodas
Open Source developer
+595-983-161124
PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
--
César D. Rodas
Open Source developer
+595-983-161124
PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
hi,
During discussion of different ways of implementing "Design by Contract"
we got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
Hi Dmitry!
I think this is a great idea, but we should postpone it to PHP 7.1.
Especially if you want to make this AST based (which would require both
stabilizing the AST we return for expressions and having APIs to do codegen
based on the AST) it will require a lot of work both for design and
implementation. I don't think it's realistic to include a high-quality
implementation in PHP 7.
As this does not have any BC concerns that I can see, I think it would be
safer to move this to PHP 7.1, when we will have more time to carefully
design this.
Nikita
The implementation is not going to be simple, and taking in account other
tasks, it may be difficult to provide high-quality implementation. Lets
look if it's really a desirable feature. Then I may do all my best, or
forget about it by 7.1.
Thanks. Dmitry.
hi,
During discussion of different ways of implementing "Design by Contract"
we got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
Hi Dmitry!
I think this is a great idea, but we should postpone it to PHP 7.1.
Especially if you want to make this AST based (which would require both
stabilizing the AST we return for expressions and having APIs to do codegen
based on the AST) it will require a lot of work both for design and
implementation. I don't think it's realistic to include a high-quality
implementation in PHP 7.As this does not have any BC concerns that I can see, I think it would be
safer to move this to PHP 7.1, when we will have more time to carefully
design this.Nikita
Nikita Popov wrote on 16/02/2015 12:14:
I think this is a great idea, but we should postpone it to PHP 7.1.
Especially if you want to make this AST based (which would require both
stabilizing the AST we return for expressions and having APIs to do codegen
based on the AST) it will require a lot of work both for design and
implementation. I don't think it's realistic to include a high-quality
implementation in PHP 7.
Is there any value in deciding the initial syntax for 7.0, and
implementing only non-parameterised annotations, i.e. you can call
hasAnnotation(string): bool but nothing else?
This wouldn't be enough to migrate existing annotation frameworks or
implement DbC and AOP, but it would mean we weren't adding a major
syntax element in a .1 release, which just feels tidier to me somehow.
It also commits us to a roadmap to implement it, rather than just
putting off all the decisions for another year.
Regards,
Rowan Collins
[IMSoP]
this will work, of course, and robust implementation wouldn't take more
than a day :)
but it'll require user-level parser again. no big advantage in comparison
to doc-block.
Thanks. Dmitry.
On Mon, Feb 16, 2015 at 6:41 PM, Rowan Collins rowan.collins@gmail.com
wrote:
Nikita Popov wrote on 16/02/2015 12:14:
I think this is a great idea, but we should postpone it to PHP 7.1.
Especially if you want to make this AST based (which would require both
stabilizing the AST we return for expressions and having APIs to do
codegen
based on the AST) it will require a lot of work both for design and
implementation. I don't think it's realistic to include a high-quality
implementation in PHP 7.Is there any value in deciding the initial syntax for 7.0, and
implementing only non-parameterised annotations, i.e. you can call
hasAnnotation(string): bool but nothing else?This wouldn't be enough to migrate existing annotation frameworks or
implement DbC and AOP, but it would mean we weren't adding a major syntax
element in a .1 release, which just feels tidier to me somehow.It also commits us to a roadmap to implement it, rather than just putting
off all the decisions for another year.Regards,
Rowan Collins
[IMSoP]
On Mon, Feb 16, 2015 at 6:41 PM, Rowan Collins <rowan.collins@gmail.com
mailto:rowan.collins@gmail.com> wrote:
Is there any value in deciding the initial syntax for 7.0, and
implementing only non-parameterised annotations, i.e. you can call
hasAnnotation(string): bool but nothing else?
Dmitry Stogov wrote on 16/02/2015 16:02:
this will work, of course, and robust implementation wouldn't take
more than a day :)
but it'll require user-level parser again. no big advantage in
comparison to doc-block.
No user-level parser would be required (or even possible), because
parameters would be illegal, not just unparsed.
So, for example, the following would be legal in 7.0:
<<IsMagic>>
function foo() { }
if ( (new ReflectionFunction('foo'))->hasAnnotation('IsMagic') ) ...
But the following would be illegal, even though a similar syntax would
be being prototyped for use in 7.1:
<<HasMagic('Expelliamus!')>>
function foo() { }
$magic = (new ReflectionFunction('foo'))->getAnnotation('HasMagic');
A few use cases would be possible just with boolean flags, and it would
give us a base to work with going forward.
It also avoids the situation (as discussed in another thread) of trying
to implement every detail of the implementation of the feature before
checking for consensus. In this case we can check that people are in
favour of:
- adding annotations as a core feature
- the basic syntax (<Foo>, <<Foo>>, [Foo], @Foo, etc)
If there's an overwhelming Yes, that's a confidence boost for whoever
works on the harder parts over the following months.
Regards,
Rowan Collins
[IMSoP]
this won't implement features necessary for phpDocumentor, Doctrine, etc.
On Mon, Feb 16, 2015 at 8:29 PM, Rowan Collins rowan.collins@gmail.com
wrote:
On Mon, Feb 16, 2015 at 6:41 PM, Rowan Collins <rowan.collins@gmail.com
mailto:rowan.collins@gmail.com> wrote:Is there any value in deciding the initial syntax for 7.0, and
implementing only non-parameterised annotations, i.e. you can call
hasAnnotation(string): bool but nothing else?Dmitry Stogov wrote on 16/02/2015 16:02:
this will work, of course, and robust implementation wouldn't take more
than a day :)
but it'll require user-level parser again. no big advantage in comparison
to doc-block.No user-level parser would be required (or even possible), because
parameters would be illegal, not just unparsed.So, for example, the following would be legal in 7.0:
<<IsMagic>>
function foo() { }if ( (new ReflectionFunction('foo'))->hasAnnotation('IsMagic') ) ...
But the following would be illegal, even though a similar syntax would be
being prototyped for use in 7.1:<<HasMagic('Expelliamus!')>>
function foo() { }$magic = (new ReflectionFunction('foo'))->getAnnotation('HasMagic');
A few use cases would be possible just with boolean flags, and it would
give us a base to work with going forward.It also avoids the situation (as discussed in another thread) of trying to
implement every detail of the implementation of the feature before checking
for consensus. In this case we can check that people are in favour of:
- adding annotations as a core feature
- the basic syntax (<Foo>, <<Foo>>, [Foo], @Foo, etc)
If there's an overwhelming Yes, that's a confidence boost for whoever
works on the harder parts over the following months.Regards,
Rowan Collins
[IMSoP]
Dmitry Stogov wrote on 16/02/2015 18:41:
this won't implement features necessary for phpDocumentor, Doctrine, etc.
I know.
Like I say, it's just a way of keeping things moving, rather than saying
"eh, maybe next year".
It allows us to formally agree the feature, the roadmap, the basic
syntax, and have a small feature that might be useful for a handful of
people, while leaving wide open what would go in the parameter brackets,
and how it would be parsed and presented to userland.
(Also, please stop top-posting, per
http://git.php.net/?p=php-src.git;a=blob_plain;f=README.MAILINGLIST_RULES;hb=HEAD)
Cheers,
Rowan Collins
[IMSoP]
this won't implement features necessary for phpDocumentor, Doctrine, etc.
Just be careful here with phpDocumentor, it does not use annotations but
really needs docblocks instead.
Today the overlap between it and doctrine and such is just matching syntax,
but it for example does not support parametrized annotations.
So let's just stick to Doctrine and other annotation specific libs for
reference of userland implementations.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://www.amsterdamphp.nl <http://wwwamsterdamphp.nl
hi,
During discussion of different ways of implementing "Design by Contract" we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
Hello,
I'd personally suggest you to consider that the Annotations could be
classes, something along the lines of
https://msdn.microsoft.com/en-us/library/aa288454%28v=vs.71%29.aspx#vcwlkattributestutorialanchor1
IMHO it will allow for more usecases and such than simple arrays.
Regards
Pavel Kouril
hi,
During discussion of different ways of implementing "Design by Contract"
we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
Hello,
I'd personally suggest you to consider that the Annotations could be
classes, something along the lines ofhttps://msdn.microsoft.com/en-us/library/aa288454%28v=vs.71%29.aspx#vcwlkattributestutorialanchor1
IMHO it will allow for more usecases and such than simple arrays.
They are statements, so you can do whatever. Dimitri just showed scalars,
but it would be possible to do:
<orm(new Entity(["repositoryClass" => "FooRepository"]))>
And then getAnnotations returns something along the lines if evaluated by
the PHP Parser:
"orm" => [new Entity(....), ]
So your requirement would be possible.
Regards
Pavel Kouril
hi,
During discussion of different ways of implementing "Design by Contract"
we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide
a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
Hello,
I'd personally suggest you to consider that the Annotations could be
classes, something along the lines ofhttps://msdn.microsoft.com/en-us/library/aa288454%28v=vs.71%29.aspx#vcwlkattributestutorialanchor1
IMHO it will allow for more usecases and such than simple arrays.
They are statements, so you can do whatever. Dimitri just showed scalars,
but it would be possible to do:<orm(new Entity(["repositoryClass" => "FooRepository"]))>
And then getAnnotations returns something along the lines if evaluated by
the PHP Parser:"orm" => [new Entity(....), ]
So your requirement would be possible.
Regards
Pavel Kouril--
Hello,
while the usage of statements in annotations sound good in theory, I
find the need for using the "new" and such as ugly. Thefore, I'd
probably still prefer the C# style of doing annotations.
Regards
Pavel Kouril
Hi,
Am 16.02.2015 um 12:07 schrieb Dmitry Stogov:
HHVM already implemented similar concept
Why not borrow their syntax? Makes it easier to write stuff for both
languages.
Greets,
Dennis
our approach is more powerfull, and HHVM syntax is not sufficient.
Also <somethig> looks better than <<something>>.
anyway, syntax decorators are discussable.
Thanks. Dmitry.
On Mon, Feb 16, 2015 at 3:19 PM, Dennis Birkholz dennis@birkholz.biz
wrote:
Hi,
Am 16.02.2015 um 12:07 schrieb Dmitry Stogov:
HHVM already implemented similar concept
Why not borrow their syntax? Makes it easier to write stuff for both
languages.Greets,
Dennis
hi,
During discussion of different ways of implementing "Design by Contract" we
got an idea of using annotations.
Thanks a lot to push that forward!
BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they are
going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...
Is it the branch/fork available?
I think the best way to validate a soluton (and its specs) is to try
to port existing annotations needs using this syntax (like Doctrine's
one). Even if the syntax is different, it will show if the syntax is
powerful enough to cover what is already used. I am not saying we need
to support everything but only what is necessary to actually implement
existing annotations (which have been used for quite some time and
proven to be very useful) using this syntax.
I would also leave the docblock/comments idea out of the discussions,
it is really not what annotations are. If we can spare us that part of
the debate, we can focus on the actual specs and implementations. :)
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi!
The test there is self explainable. Of course, annotations just provide
a way to add metadata, but doesn't define attribute names or the ways
they are going to be used. Only Reflection API to read.
Looks fine, but I'm not sure how one can use the AST that the reflection
returns. Is it for extensions only?
Also, for some annotations you want values - i.e. optimization_level,
and for some - expressions. So there should be an easy way to convert
the AST to the actual value for whoever implements the annotation.
There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
I'd like to have some annotations in PHP 7, definitely.
--
Stas Malyshev
smalyshev@gmail.com
On Mon, Feb 16, 2015 at 8:41 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
The test there is self explainable. Of course, annotations just provide
a way to add metadata, but doesn't define attribute names or the ways
they are going to be used. Only Reflection API to read.Looks fine, but I'm not sure how one can use the AST that the reflection
returns. Is it for extensions only?
I don't know the best way yet.
Nikita worked in extension for AST traversing in PHP.
Also, for some annotations you want values - i.e. optimization_level,
and for some - expressions. So there should be an easy way to convert
the AST to the actual value for whoever implements the annotation.
agree.
Thanks. Dmitry.
There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?I'd like to have some annotations in PHP 7, definitely.
--
Stas Malyshev
smalyshev@gmail.com
hi,
During discussion of different ways of implementing "Design by Contract" we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2
Why didn't you pick the same syntax as hack?
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
hi,
During discussion of different ways of implementing "Design by Contract"
we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2Why didn't you pick the same syntax as hack?
It's not smart enough to be used for DbC, AOT and many other features (we
are going to capture AST).
Thanks. Dmitry.
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
hi,
During discussion of different ways of implementing "Design by Contract"
we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2Why didn't you pick the same syntax as hack?
It's not smart enough to be used for DbC, AOT and many other features (we
are going to capture AST).
I realize that, but:
<optimization_level(2)>
could easily look like:
<<optimization_level(2)>>
The latter syntax <<…>> is what Hack does, but you picked <…> - which
makes it both the same as HTML/XML tags and different from Hack. The
<…> syntax also gets in the way of XHP
(https://github.com/facebookarchive/xhp-php5-extension)
cheers,
Derick
hi,
During discussion of different ways of implementing "Design by
Contract"
we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for
different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement
annotations
in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2Why didn't you pick the same syntax as hack?
It's not smart enough to be used for DbC, AOT and many other features (we
are going to capture AST).I realize that, but:
<optimization_level(2)>
could easily look like:
<<optimization_level(2)>>
The latter syntax <<…>> is what Hack does, but you picked <…> - which
makes it both the same as HTML/XML tags and different from Hack. The
<…> syntax also gets in the way of XHP
(https://github.com/facebookarchive/xhp-php5-extension)cheers,
Derick
I don't care about decorators.
If we come to vote I may add a separate question about <> vs <<>>
Thanks. Dmitry.
hi,
During discussion of different ways of implementing "Design by Contract" we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2
How about not exposing the AST, and then the userland can pass context to a
method $reflection->getAnnotation($name, $context);
https://gist.github.com/beberlei/0dc36d4412b8e3454912
That way AST is not exposed to userland.
The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:
hi,
During discussion of different ways of implementing "Design by Contract"
we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2How about not exposing the AST, and then the userland can pass context to
a method $reflection->getAnnotation($name, $context);https://gist.github.com/beberlei/0dc36d4412b8e3454912
That way AST is not exposed to userland.
Your example handles just particular use-case.
I would like to provide a general solution.
Thanks. Dmitry.
The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Thanks. Dmitry.
On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:hi,
During discussion of different ways of implementing "Design by Contract"
we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2How about not exposing the AST, and then the userland can pass context to
a method $reflection->getAnnotation($name, $context);https://gist.github.com/beberlei/0dc36d4412b8e3454912
That way AST is not exposed to userland.
Your example handles just particular use-case.
I would like to provide a general solution.Thanks. Dmitry.
Could you provide some more info on how you would imagine this to be used
for the DbC use case? As far as I see, this would require injecting code
into the method body based on the annotations. Does that mean that
annotations handlers will get the chance to modify the AST of the method
itself during compilation? Or how is this supposed to be realized?
Nikita
Hi Nikita,
On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:hi,
During discussion of different ways of implementing "Design by
Contract" we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement
annotations in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2How about not exposing the AST, and then the userland can pass context
to a method $reflection->getAnnotation($name, $context);https://gist.github.com/beberlei/0dc36d4412b8e3454912
That way AST is not exposed to userland.
Your example handles just particular use-case.
I would like to provide a general solution.Thanks. Dmitry.
Could you provide some more info on how you would imagine this to be used
for the DbC use case? As far as I see, this would require injecting code
into the method body based on the annotations. Does that mean that
annotations handlers will get the chance to modify the AST of the method
itself during compilation? Or how is this supposed to be realized?
In general, it must be possible to plug into compilation process using
zend_ast_process() callback and modify function AST, inserting constraints
validation in proper places.
But for now, I'm thinking only about metadata syntax and representation. I
just showed, how it can be used to represent DbC constraints.
I don't think we need user-level interface to modify AST.
Thanks. Dmitry.
Nikita
Hi Nikita,
On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov nikita.ppv@gmail.com
wrote:On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmitry@zend.com
wrote:hi,
During discussion of different ways of implementing "Design by
Contract" we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement
annotations in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2How about not exposing the AST, and then the userland can pass context
to a method $reflection->getAnnotation($name, $context);https://gist.github.com/beberlei/0dc36d4412b8e3454912
That way AST is not exposed to userland.
Your example handles just particular use-case.
I would like to provide a general solution.Thanks. Dmitry.
Could you provide some more info on how you would imagine this to be used
for the DbC use case? As far as I see, this would require injecting code
into the method body based on the annotations. Does that mean that
annotations handlers will get the chance to modify the AST of the method
itself during compilation? Or how is this supposed to be realized?In general, it must be possible to plug into compilation process using
zend_ast_process() callback and modify function AST, inserting constraints
validation in proper places.
But for now, I'm thinking only about metadata syntax and representation. I
just showed, how it can be used to represent DbC constraints.
I don't think we need user-level interface to modify AST.
To make sure I got it right: The AST-based annotations are only there to
allow handling by PHP extensions (or the engine itself), while evaluated
annotations are there for use by userland code?
Nikita
Hi Nikita,
On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov nikita.ppv@gmail.com
wrote:On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei <kontakt@beberlei.de
wrote:
On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmitry@zend.com
wrote:hi,
During discussion of different ways of implementing "Design by
Contract" we
got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement
annotations in
PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2How about not exposing the AST, and then the userland can pass context
to a method $reflection->getAnnotation($name, $context);https://gist.github.com/beberlei/0dc36d4412b8e3454912
That way AST is not exposed to userland.
Your example handles just particular use-case.
I would like to provide a general solution.Thanks. Dmitry.
Could you provide some more info on how you would imagine this to be
used for the DbC use case? As far as I see, this would require injecting
code into the method body based on the annotations. Does that mean that
annotations handlers will get the chance to modify the AST of the method
itself during compilation? Or how is this supposed to be realized?In general, it must be possible to plug into compilation process using
zend_ast_process() callback and modify function AST, inserting constraints
validation in proper places.
But for now, I'm thinking only about metadata syntax and representation.
I just showed, how it can be used to represent DbC constraints.
I don't think we need user-level interface to modify AST.To make sure I got it right: The AST-based annotations are only there to
allow handling by PHP extensions (or the engine itself), while evaluated
annotations are there for use by userland code?Nikita
I think yes,
However, Alexander thinks differently
https://wiki.php.net/rfc/parser-extension-api
Of course this is not for 7.0
Thanks. Dmitry.
2015-02-17 19:25 GMT+03:00 Dmitry Stogov dmitry@zend.com:
I think yes,
However, Alexander thinks differently
https://wiki.php.net/rfc/parser-extension-api
Of course this is not for 7.0
This RFC consists of two parts: parsing API and parser extension API. Last
one can be rejected, however it can be perfectly connected with annotation
RFC (if AST will be used as values)
As for annotations, general use-case is appreciated. This can be extended
later in future versions of PHP. Therefore, annotation syntax should allow
to define key and values. Value can be valid expression (AST? concrete
node? compiled value?) or can recursively contain nested annotations.
Hi Alexander,
De : Alexander Lisachenko [mailto:lisachenko.it@gmail.com]
This RFC consists of two parts: parsing API and parser extension API. Last
one can be rejected, however it can be perfectly connected with annotation
RFC (if AST will be used as values)
Parser extension API is great. Go on with it. I have a lot of uses in mind.
As for annotations, general use-case is appreciated. This can be extended
later in future versions of PHP. Therefore, annotation syntax should allow
to define key and values. Value can be valid expression (AST? concrete
node? compiled value?) or can recursively contain nested annotations.
Can you give a use case for nested annotations ? I don't see what they can be needed for.
Thanks
François
François,
Doctrine relies on nested annotations for a variety of mapping information.
One example:
[]s,
On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre francois@php.net
wrote:
Hi Alexander,
De : Alexander Lisachenko [mailto:lisachenko.it@gmail.com]
This RFC consists of two parts: parsing API and parser extension API.
Last
one can be rejected, however it can be perfectly connected with
annotation
RFC (if AST will be used as values)Parser extension API is great. Go on with it. I have a lot of uses in mind.
As for annotations, general use-case is appreciated. This can be extended
later in future versions of PHP. Therefore, annotation syntax should
allow
to define key and values. Value can be valid expression (AST? concrete
node? compiled value?) or can recursively contain nested annotations.Can you give a use case for nested annotations ? I don't see what they can
be needed for.Thanks
François
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
On Wed, Feb 18, 2015 at 12:51 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
François,
Doctrine relies on nested annotations for a variety of mapping information.
One example:
Nested annotations are not going to be necessary, because they may be
represented by PHP pseudo-syntax (and/or PHP array syntax)
<Doctrine_Join(
ManyToMany($targetEntity="Phonenumber"),
JoinTable($name="users_phonenumbers",
$joinColumns=JoinColumn($name="user_id",
$referencedColumnName="id"))
inverseJoinColumns=JoinColumn($name="phonenumber_id",
$referencedColumnName="id", $unique=true))>
class User {
...
}
$r = new ReflectionClass("User");
$ast = $r->getAnnotation("Doctine_Join");
echo $ast->child[0]->child[0]; // "ManyToMany"
echo $ast->child[0]->child[1]->child[0]->child[0]; // "$targetEntity"
or If we provide API similar to SimpleXML
echo $ast[0][0]; // "ManyToMany"
echo $ast[0][1][0][0]; // "$targetEntity"
Thanks. Dmitry.
[]s,
On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre francois@php.net
wrote:Hi Alexander,
De : Alexander Lisachenko [mailto:lisachenko.it@gmail.com]
This RFC consists of two parts: parsing API and parser extension API.
Last
one can be rejected, however it can be perfectly connected with
annotation
RFC (if AST will be used as values)Parser extension API is great. Go on with it. I have a lot of uses in
mind.As for annotations, general use-case is appreciated. This can be
extended
later in future versions of PHP. Therefore, annotation syntax should
allow
to define key and values. Value can be valid expression (AST? concrete
node? compiled value?) or can recursively contain nested annotations.Can you give a use case for nested annotations ? I don't see what they
can be needed for.Thanks
François
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
On Wed, Feb 18, 2015 at 12:51 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:François,
Doctrine relies on nested annotations for a variety of mapping
information.
One example:Nested annotations are not going to be necessary, because they may be
represented by PHP pseudo-syntax (and/or PHP array syntax)<Doctrine_Join(
ManyToMany($targetEntity="Phonenumber"),
JoinTable($name="users_phonenumbers",
$joinColumns=JoinColumn($name="user_id",
$referencedColumnName="id"))
inverseJoinColumns=JoinColumn($name="phonenumber_id",
$referencedColumnName="id", $unique=true))>
class User {
...
}$r = new ReflectionClass("User");
$ast = $r->getAnnotation("Doctine_Join");
echo $ast->child[0]->child[0]; // "ManyToMany"
echo $ast->child[0]->child[1]->child[0]->child[0]; // "$targetEntity"or If we provide API similar to SimpleXML
echo $ast[0][0]; // "ManyToMany"
echo $ast[0][1][0][0]; // "$targetEntity"Thanks. Dmitry.
nested can be done in any way, its a statement so the following would work:
<orm(new JoinTable(['joinColumns' => [new JoinColumn('id', 'other_id')]]))>
You might need to improve this by defining functions, so that "new
JoinTable" becomes just "JoinTable", but in any case we will find a way to
make it work in Doctrine.
[]s,
On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre francois@php.net
wrote:Hi Alexander,
De : Alexander Lisachenko [mailto:lisachenko.it@gmail.com]
This RFC consists of two parts: parsing API and parser extension API.
Last
one can be rejected, however it can be perfectly connected with
annotation
RFC (if AST will be used as values)Parser extension API is great. Go on with it. I have a lot of uses in
mind.As for annotations, general use-case is appreciated. This can be
extended
later in future versions of PHP. Therefore, annotation syntax should
allow
to define key and values. Value can be valid expression (AST? concrete
node? compiled value?) or can recursively contain nested annotations.Can you give a use case for nested annotations ? I don't see what they
can be needed for.Thanks
François
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
On Wed, Feb 18, 2015 at 11:05 AM, Benjamin Eberlei kontakt@beberlei.de
wrote:
On Wed, Feb 18, 2015 at 12:51 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:François,
Doctrine relies on nested annotations for a variety of mapping
information.
One example:Nested annotations are not going to be necessary, because they may be
represented by PHP pseudo-syntax (and/or PHP array syntax)<Doctrine_Join(
ManyToMany($targetEntity="Phonenumber"),
JoinTable($name="users_phonenumbers",
$joinColumns=JoinColumn($name="user_id",
$referencedColumnName="id"))
inverseJoinColumns=JoinColumn($name="phonenumber_id",
$referencedColumnName="id", $unique=true))>
class User {
...
}$r = new ReflectionClass("User");
$ast = $r->getAnnotation("Doctine_Join");
echo $ast->child[0]->child[0]; // "ManyToMany"
echo $ast->child[0]->child[1]->child[0]->child[0]; // "$targetEntity"or If we provide API similar to SimpleXML
echo $ast[0][0]; // "ManyToMany"
echo $ast[0][1][0][0]; // "$targetEntity"Thanks. Dmitry.
nested can be done in any way, its a statement so the following would work:
<orm(new JoinTable(['joinColumns' => [new JoinColumn('id', 'other_id')]]))>
You might need to improve this by defining functions, so that "new
JoinTable" becomes just "JoinTable", but in any case we will find a way to
make it work in Doctrine.
Are you (and Doctrine team) interested in this annotation idea?
Thanks. Dmitry.
[]s,
On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre francois@php.net
wrote:Hi Alexander,
De : Alexander Lisachenko [mailto:lisachenko.it@gmail.com]
This RFC consists of two parts: parsing API and parser extension API.
Last
one can be rejected, however it can be perfectly connected with
annotation
RFC (if AST will be used as values)Parser extension API is great. Go on with it. I have a lot of uses in
mind.As for annotations, general use-case is appreciated. This can be
extended
later in future versions of PHP. Therefore, annotation syntax should
allow
to define key and values. Value can be valid expression (AST? concrete
node? compiled value?) or can recursively contain nested annotations.Can you give a use case for nested annotations ? I don't see what they
can be needed for.Thanks
François
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
De : Benjamin Eberlei [mailto:kontakt@beberlei.de]
nested can be done in any way, its a statement so the following would work:
<orm(new JoinTable(['joinColumns' => [new JoinColumn('id', 'other_id')]]))>
Dmitry is planning compile time evaluation, which is probably the only way to do it if we use PHP expressions. Is class instantiation, or function call returning a new object instance (I guess) compatible with compile time evaluation ?
More : would userland functions be available (if already defined, of course) ? if yes, what about functions defined in the same file but below the annotation calling it ? Two-pass ?
Regards
François
On Wed, Feb 18, 2015 at 3:01 PM, François Laupretre francois@php.net
wrote:
De : Benjamin Eberlei [mailto:kontakt@beberlei.de]
nested can be done in any way, its a statement so the following would
work:<orm(new JoinTable(['joinColumns' => [new JoinColumn('id',
'other_id')]]))>Dmitry is planning compile time evaluation, which is probably the only way
to do it if we use PHP expressions. Is class instantiation, or function
call returning a new object instance (I guess) compatible with compile time
evaluation ?More : would userland functions be available (if already defined, of
course) ? if yes, what about functions defined in the same file but below
the annotation calling it ? Two-pass ?Regards
François
I answer the last time.
Annotations is just a key value storage, where value may be AST for php
expression.
Your may do with it whatever you like (traverse, evaluate, compile), but
PHP core itself is not going to do anything.
Thanks. Dmitry.
Hi Dmitry,
Right. That’s what I got from your last reply. But my question was about another post where you are talking about ‘compile time evaluation’ of expressions, which is different from the bare key/value storage I understood first, and poses the problem of compile time evaluation scope (which also exists at runtime).
If you just store the expression as a bare string or AST without evaluating it, that’s fine and, even, much better from a performance point of view. I just want to make it clear for me and everyone that there will be no possibility of compile time evaluation. That’s all.
Again, sorry to insist ;).
François
I answer the last time.
Annotations is just a key value storage, where value may be AST for php expression.
Your may do with it whatever you like (traverse, evaluate, compile), but PHP core itself is not going to do anything.
Thanks. Dmitry.
On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre francois@php.net
wrote:
Hi Dmitry,
Right. That’s what I got from your last reply. But my question was about
another post where you are talking about ‘compile time evaluation’ of
expressions, which is different from the bare key/value storage I
understood first, and poses the problem of compile time evaluation scope
(which also exists at runtime).If you just store the expression as a bare string or AST without
evaluating it, that’s fine and, even, much better from a performance point
of view. I just want to make it clear for me and everyone that there will
be no possibility of compile time evaluation. That’s all.
right.
Again, sorry to insist ;).
no problem.
Thaks. Dmitry.
François
I answer the last time.
Annotations is just a key value storage, where value may be AST for php
expression.Your may do with it whatever you like (traverse, evaluate, compile), but
PHP core itself is not going to do anything.Thanks. Dmitry.
Hi Dmitry,
Are you (and Doctrine team) interested in this annotation idea?
I'd say that Benjamin nailed in our possible usage:
<orm(new Entity("foo"))>
class Foo {
}
Now I do feel we need to elaborate some sort of named parameters. Doctrine
tries to simplify a lot developer's life by using consistency in default
mapping and only if the user wants to override default behavior he needs to
override a given parameter. This means in a case where you're mapping a
JoinColumn (
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/JoinColumn.php
),
you may only want to specify the onDelete="CASCADE" operation instead of
name, referencedColumnName and many other parameters.
Trying to map this in your default parameter passing, we'd have something
like:
<orm(
[
new OneToOne("Address"),
new JoinColumn(default, default, default, default, "CASCADE")
]
)>
public $address;
As I said, named parameters make a lot of sense when mapping defaults.
Now by looking at this syntax, I still think we're closer to a simple array
implementation (ReflectionClass::getMetadata(string $name)) and having
something like:
<[
"orm" => [
new OneToOne("Address"),
new JoinColumn(default, default, default, default, "CASCADE")
]
]>
public $address;
PS: We haven't even started on talking about overrides yet... =\
Regards,
On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre francois@php.net
wrote:Hi Dmitry,
Right. That’s what I got from your last reply. But my question was about
another post where you are talking about ‘compile time evaluation’ of
expressions, which is different from the bare key/value storage I
understood first, and poses the problem of compile time evaluation scope
(which also exists at runtime).If you just store the expression as a bare string or AST without
evaluating it, that’s fine and, even, much better from a performance point
of view. I just want to make it clear for me and everyone that there will
be no possibility of compile time evaluation. That’s all.right.
Again, sorry to insist ;).
no problem.
Thaks. Dmitry.
François
I answer the last time.
Annotations is just a key value storage, where value may be AST for php
expression.Your may do with it whatever you like (traverse, evaluate, compile), but
PHP core itself is not going to do anything.Thanks. Dmitry.
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
On Wed, Feb 18, 2015 at 7:28 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
Hi Dmitry,
Are you (and Doctrine team) interested in this annotation idea?
I'd say that Benjamin nailed in our possible usage:
<orm(new Entity("foo"))>
class Foo {
}Now I do feel we need to elaborate some sort of named parameters. Doctrine
tries to simplify a lot developer's life by using consistency in default
mapping and only if the user wants to override default behavior he needs to
override a given parameter. This means in a case where you're mapping a
JoinColumn (
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/JoinColumn.php
),
you may only want to specify the onDelete="CASCADE" operation instead of
name, referencedColumnName and many other parameters.
Trying to map this in your default parameter passing, we'd have something
like:<orm(
[
new OneToOne("Address"),
new JoinColumn(default, default, default, default, "CASCADE")
]
)>
public $address;As I said, named parameters make a lot of sense when mapping defaults.
Now by looking at this syntax, I still think we're closer to a simple array
implementation (ReflectionClass::getMetadata(string $name)) and having
something like:<[
"orm" => [
new OneToOne("Address"),
new JoinColumn(default, default, default, default, "CASCADE")
]
]>
public $address;PS: We haven't even started on talking about overrides yet... =\
As a Doctrine user, I find this way worse than current state. This
syntax looks UGLY and contains a lot of useless clutter. And yeah,
adding named parameters to PHP be pretty helpful to make annotations
more readable. :(
And to what Francois said ("Anyway, I don't like the OO features
people want to add everywhere. They can get strings and inject them to
OO, but that's not the role of the annotation layer, IMHO. I
definitely prefer the KISS approach."). What's exactly wrong with
doing annotations in an object oriented manner? Both Doctrine
Annotations and C# have them as objects, and it works well. Having
annotations as just array of expressions/strings/whatever and needing
another library to parse them is not really that great "upgrade" from
current state. :(
Regards
Pavel Kouril
On Wed, Feb 18, 2015 at 7:28 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Hi Dmitry,
Are you (and Doctrine team) interested in this annotation idea?
I'd say that Benjamin nailed in our possible usage:
<orm(new Entity("foo"))>
class Foo {
}Now I do feel we need to elaborate some sort of named parameters.
Doctrine
tries to simplify a lot developer's life by using consistency in default
mapping and only if the user wants to override default behavior he needs
to
override a given parameter. This means in a case where you're mapping a
JoinColumn (https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/JoinColumn.php
),
you may only want to specify the onDelete="CASCADE" operation instead of
name, referencedColumnName and many other parameters.
Trying to map this in your default parameter passing, we'd have something
like:<orm(
[
new OneToOne("Address"),
new JoinColumn(default, default, default, default, "CASCADE")
]
)>
public $address;As I said, named parameters make a lot of sense when mapping defaults.
Now by looking at this syntax, I still think we're closer to a simple
array
implementation (ReflectionClass::getMetadata(string $name)) and having
something like:<[
"orm" => [
new OneToOne("Address"),
new JoinColumn(default, default, default, default, "CASCADE")
]
]>
public $address;PS: We haven't even started on talking about overrides yet... =\
As a Doctrine user, I find this way worse than current state. This
syntax looks UGLY and contains a lot of useless clutter. And yeah,
adding named parameters to PHP be pretty helpful to make annotations
more readable. :(
This is in no way related, only by the choice of guilherme's syntax. You
could
pass an array of options to the constructor to simulate named easily.
And to what Francois said ("Anyway, I don't like the OO features
people want to add everywhere. They can get strings and inject them to
OO, but that's not the role of the annotation layer, IMHO. I
definitely prefer the KISS approach."). What's exactly wrong with
doing annotations in an object oriented manner? Both Doctrine
Annotations and C# have them as objects, and it works well. Having
annotations as just array of expressions/strings/whatever and needing
another library to parse them is not really that great "upgrade" from
current state. :(
PHP is not primarily an OOP language. As a user of Doctrine you wouldn't
need to care,
because we would wrap it anyway in our current code. So it wouldn't matter.
Regards
Pavel Kouril
Hi List,
<orm(new Entity("foo"))>
this may be off-topic. However i'm wondering how this could be an
annotation? It looks like code. Why not include this into proper method?
What am i missing?
As a Doctrine user, I find this way worse than current state. This
syntax looks UGLY and contains a lot of useless clutter. And yeah,
adding named parameters to PHP be pretty helpful to make annotations
more readable. :(This is in no way related, only by the choice of guilherme's syntax. You
could
pass an array of options to the constructor to simulate named easily.
Sorry, but I find passing an array with fields instead of proper named
parameters as a hack, not as a solution. :(
And to what Francois said ("Anyway, I don't like the OO features
people want to add everywhere. They can get strings and inject them to
OO, but that's not the role of the annotation layer, IMHO. I
definitely prefer the KISS approach."). What's exactly wrong with
doing annotations in an object oriented manner? Both Doctrine
Annotations and C# have them as objects, and it works well. Having
annotations as just array of expressions/strings/whatever and needing
another library to parse them is not really that great "upgrade" from
current state. :(PHP is not primarily an OOP language. As a user of Doctrine you wouldn't
need to care,
because we would wrap it anyway in our current code. So it wouldn't matter.
I know you could wrap it in your code, but that would still mean there
would probably be multiple implementations of Annotations in the
"wild", instead of a good complete functionality in the language
itself.
I know PHP is not primarily an OOP language, but Annotations IMHO make
sense as classes, so I don't see any reason why would it be bad to
make them in that way. Also, making Annotations be classes won't
magically turn PHP into a primarily OOP language?
Regards
Pavel Kouřil
I know you could wrap it in your code, but that would still mean there
would probably be multiple implementations of Annotations in the
"wild", instead of a good complete functionality in the language
itself.I know PHP is not primarily an OOP language, but Annotations IMHO make
sense as classes, so I don't see any reason why would it be bad to
make them in that way. Also, making Annotations be classes won't
magically turn PHP into a primarily OOP language?Regards
Pavel Kouřil
If you look at the major projects and code in the wild, PHP is a
primarily OOP language and has been for years. It's multi-paradigm but
OOP is the dominant style in the wild today.
And I think mapping annotations to classes is a fine idea, as it means I
can very easily document what a given annotations is for (it's a class,
document the class), extend it, and build meaningful functionality and
defaults using an already well-known syntax and convention.
--Larry Garfield
One thing to consider when annotations are classes is whether using an
annotation should make the annotated class depend on the annotation
classes it uses. In other words, would a missing annotation class
produce an error? It doesn't in Java (at runtime, see
http://stackoverflow.com/a/3567969) and I think they made the right
choice on that (although you can't compare this directly to PHP due to
the nature of compilation in Java, and it is still a compile error
there).
Consider an entity class with Doctrine mappings in annotations. This
class is still perfectly usable on its own without this persistence
information (assuming you don't care about database persistence in
such situations), just as it would be if the mapping information was
in XML/YAML files instead. I don't think Doctrine should be a hard
dependency of such a class.
Of course the code that reads the annotations still depends on the
annotation classes it cares about.
2015-02-25 5:27 GMT+01:00 Larry Garfield larry@garfieldtech.com:
I know you could wrap it in your code, but that would still mean there
would probably be multiple implementations of Annotations in the
"wild", instead of a good complete functionality in the language
itself.I know PHP is not primarily an OOP language, but Annotations IMHO make
sense as classes, so I don't see any reason why would it be bad to
make them in that way. Also, making Annotations be classes won't
magically turn PHP into a primarily OOP language?Regards
Pavel KouřilIf you look at the major projects and code in the wild, PHP is a primarily
OOP language and has been for years. It's multi-paradigm but OOP is the
dominant style in the wild today.And I think mapping annotations to classes is a fine idea, as it means I can
very easily document what a given annotations is for (it's a class, document
the class), extend it, and build meaningful functionality and defaults using
an already well-known syntax and convention.--Larry Garfield
One thing to consider when annotations are classes is whether using an
annotation should make the annotated class depend on the annotation
classes it uses. In other words, would a missing annotation class
produce an error? It doesn't in Java (at runtime, see
http://stackoverflow.com/a/3567969) and I think they made the right
choice on that (although you can't compare this directly to PHP due to
the nature of compilation in Java, and it is still a compile error
there).Consider an entity class with Doctrine mappings in annotations. This
class is still perfectly usable on its own without this persistence
information (assuming you don't care about database persistence in
such situations), just as it would be if the mapping information was
in XML/YAML files instead. I don't think Doctrine should be a hard
dependency of such a class.Of course the code that reads the annotations still depends on the
annotation classes it cares about.2015-02-25 5:27 GMT+01:00 Larry Garfield larry@garfieldtech.com:
I know you could wrap it in your code, but that would still mean there
would probably be multiple implementations of Annotations in the
"wild", instead of a good complete functionality in the language
itself.I know PHP is not primarily an OOP language, but Annotations IMHO make
sense as classes, so I don't see any reason why would it be bad to
make them in that way. Also, making Annotations be classes won't
magically turn PHP into a primarily OOP language?Regards
Pavel KouřilIf you look at the major projects and code in the wild, PHP is a primarily
OOP language and has been for years. It's multi-paradigm but OOP is the
dominant style in the wild today.And I think mapping annotations to classes is a fine idea, as it means I can
very easily document what a given annotations is for (it's a class, document
the class), extend it, and build meaningful functionality and defaults using
an already well-known syntax and convention.--Larry Garfield
Consistent top/bottom posting please... this is a bottom-posting-thread.
And yes, I agree that we shouldn't make absence of an
annotation-referenced class an error until the annotation is actually
read. Until the annotations is used, the class shouldn't be loaded so
it's ignored.
--Larry Garfield
Hi Dmitry,
De : Dmitry Stogov [mailto:dmitry@zend.com]
Nested annotations are not going to be necessary, because they may be
represented by PHP pseudo-syntax (and/or PHP array syntax)<Doctrine_Join(
ManyToMany($targetEntity="Phonenumber"),
JoinTable($name="users_phonenumbers",
$joinColumns=JoinColumn($name="user_id",
$referencedColumnName="id"))
inverseJoinColumns=JoinColumn($name="phonenumber_id",
$referencedColumnName="id", $unique=true))>
class User {
...
}$r = new ReflectionClass("User");
$ast = $r->getAnnotation("Doctine_Join");
echo $ast->child[0]->child[0]; // "ManyToMany"
echo $ast->child[0]->child[1]->child[0]->child[0]; // "$targetEntity"or If we provide API similar to SimpleXML
echo $ast[0][0]; // "ManyToMany"
echo $ast[0][1][0][0]; // "$targetEntity"
Please, no new pseudo language. Either value is a bare string and application has responsibility to parse it, or it is a PHP expression, especially since we have short array syntax. If user needs runtime evaluation, as in DbC, he just passes his expression in a string.
Accessing ast elements by index is quite poor too, and if it is to define associative pseudo-arrays, let's use PHP arrays.
Also, a detail, same as Derick's : '<>' reminds html/xml too much, IMO. While completely different, it will confuse a lot of people. I prefer '<<>>'. No ambiguity.
So :
<<Doctrine_Join([
'ManyToMany' => [ 'targetEntity' => "Phonenumber" ],
'JoinTable' => [
'name' => "users_phonenumbers" ,
'joinColumns' => [
[ 'name' => 'user_id', 'referencedColumnName' => 'id' ]
],
'inverseJoinColumns' => [
[ 'name' => "phonenumber_id", 'referencedColumnName' => "id", 'unique' => true ]
]
]
] ) >>
A last question: in such a case, should '<<' strings appearing in the expression have to be quoted, or would it take care of string delimiters when searching for the end of the annotation ?
Regards
François
On Tue, Feb 17, 2015 at 10:13 PM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:
2015-02-17 19:25 GMT+03:00 Dmitry Stogov dmitry@zend.com:
I think yes,
However, Alexander thinks differently
https://wiki.php.net/rfc/parser-extension-api
Of course this is not for 7.0This RFC consists of two parts: parsing API and parser extension API. Last
one can be rejected, however it can be perfectly connected with annotation
RFC (if AST will be used as values)
firs part may be accepted.
The second can't be accepted for 7.0 just because of time limit. (we have
feature freeze in a month)
As for annotations, general use-case is appreciated. This can be extended
later in future versions of PHP. Therefore, annotation syntax should allow
to define key and values. Value can be valid expression (AST? concrete
node? compiled value?) or can recursively contain nested annotations.
Annotaion syntax: <key(php-expression-value)>
"php-expression-value" is parsed by standard PHP parser into AST. This AST
is stored in annotations table at slot "key".
Constant expressions are evaluated at compile-time and we store only the
resulting constant value.
Then it's possible to retrieve this AST (or value) using Reflection API.
ReflectionMethod->getAnnotations();
ReflectionMethod->hasAnnotation(string $key);
ReflectionMethod->getAnnotation(string $key);
Then it's possible to traverse AST using some API like
https://github.com/nikic/php-ast
It also should be possible to evaluate retrieved "php-expression-value" in
some context and reconstruct PHP source for any AST node.
Thanks. Dmitry.
Hi Dmitry,
During discussion of different ways of implementing "Design by Contract"
we got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...
Although, I prefer simple DbC as PHP syntax, my priority is introducing DbC
to PHP. No problem for me.
For both annotation and PHP syntax, we should concentrate "simple" (i.e.
without strong type safety. Don't read me wrong, I'm not saying without
type check) DbC. IMHO.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Dmitry,
During discussion of different ways of implementing "Design by Contract"
we got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...Although, I prefer simple DbC as PHP syntax, my priority is introducing DbC
to PHP. No problem for me.
I don't have strong opinion - what is better for DbC, PHP syntax or
annotations.
Now I made some research on annotations, because I think it may be useful
not only for DbC.
Thanks. Dmitry.
For both annotation and PHP syntax, we should concentrate "simple" (i.e.
without strong type safety. Don't read me wrong, I'm not saying without
type check) DbC. IMHO.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Dmitry,
During discussion of different ways of implementing "Design by Contract"
we got an idea of using annotations.BTW: annotations are useful by their own and may be used for different
purposes. Support for annotations was proposed long time ago:https://wiki.php.net/rfc/annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/reflection_doccomment_annotationsHHVM already implemented similar concept
http://docs.hhvm.com/manual/en/hack.attributes.php
I made a quick and dirty PoC that shows how we may implement annotations
in PHP7 and how powerful they may be :
https://gist.github.com/dstogov/dbf2a8f46e43719bd2c2The test there is self explainable. Of course, annotations just provide a
way to add metadata, but doesn't define attribute names or the ways they
are going to be used. Only Reflection API to read.There are still a lot of technical problems that have to be solved.
Right now, we just need to answer a question - if we like this in PHP7?
Thought and opinions are welcome...
I also would like to introduce AOP in the future. (or with it)
I thought something like
https://github.com/AOP-PHP/AOP
is good, but we may use annotations. With annotations, we must
define pointcut/etc manually, but AOP by annotation is more
flexible than AspectJ.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net