Re: [PHP-DEV] Annotations in PHP7
On 2/25/15 5:45 AM, Peter Holák wrote: 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 la...@garfieldtech.com: On 02/21/2015 03:35 PM, Pavel Kouřil wrote: 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
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 la...@garfieldtech.com: On 02/21/2015 03:35 PM, Pavel Kouřil wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On 02/21/2015 03:35 PM, Pavel Kouřil wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 9:45 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil pajou...@gmail.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
Am 19.02.2015 um 08:14 schrieb Dmitry Stogov: On Thu, Feb 19, 2015 at 2:12 AM, François Laupretre franc...@php.net mailto:franc...@php.net wrote: If I understand Dmitry correctly, this would be stored as the compiler internal representation of the 'new Entity(foo)' code, but this wouldn't be executed until an external mechanism decides to do so. So, this is PHP code and it is compiled and stored in memory besides the function opcodes, but not evaluated. Right. It's even not compiled into bytecode, just parsed into AST and then associated with function/class/property like doc-comment. You're right, it contains code. The key point is that this code will never be executed nor used in any way until an external mechanism decides to retrieve and evaluate it. That's metadata. Right again. Hi, thank you for the answers. I understand the anything is possible argument and would like to see/push future ideas in direction of domain-specific languages (DSL) opposite to another aspect-oriented programming (AOP) extension as in current examples. Sorry for offtopic. Thanks cryptocompress
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 11:05 AM, Benjamin Eberlei kont...@beberlei.de
wrote:
On Wed, Feb 18, 2015 at 8:02 AM, Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 18, 2015 at 12:51 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
François,
Doctrine relies on nested annotations for a variety of mapping
information.
One example:
http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table
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 franc...@php.net
wrote:
Hi Alexander,
De : Alexander Lisachenko [mailto:lisachenko...@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: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 8:02 AM, Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 18, 2015 at 12:51 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
François,
Doctrine relies on nested annotations for a variety of mapping
information.
One example:
http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table
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 franc...@php.net
wrote:
Hi Alexander,
De : Alexander Lisachenko [mailto:lisachenko...@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: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 11:59 AM, Derick Rethans der...@php.net wrote: On Tue, 17 Feb 2015, Dmitry Stogov wrote: On Mon, Feb 16, 2015 at 10:57 PM, Derick Rethans der...@php.net wrote: On Mon, 16 Feb 2015, Dmitry Stogov 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_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 Why 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.
Re: [PHP-DEV] Annotations in PHP7
On Tue, 17 Feb 2015, Dmitry Stogov wrote: On Mon, Feb 16, 2015 at 10:57 PM, Derick Rethans der...@php.net wrote: On Mon, 16 Feb 2015, Dmitry Stogov 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_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 Why 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre franc...@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.
Re: [PHP-DEV] Annotations in PHP7
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 12:04 PM, Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre franc...@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: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com
guilhermebla...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Annotations in PHP7
Hi Guilherme, De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] orm( [ new OneToOne(Address), new JoinColumn(default, default, default, default, CASCADE) ] ) public $address; Why not : orm([ 'OneToOne' = Address, 'JoinColumns' = [ [ 'onDelete' = CASCADE ] ] ]) Can't array keys replace named parameters ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 9:40 PM, François Laupretre franc...@php.net wrote: Hi Guilherme, De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] orm( [ new OneToOne(Address), new JoinColumn(default, default, default, default, CASCADE) ] ) public $address; Why not : orm([ 'OneToOne' = Address, 'JoinColumns' = [ [ 'onDelete' = CASCADE ] ] ]) Can't array keys replace named parameters ? yes they can. Regards François
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Feb 18, 2015 at 7:28 PM, guilhermebla...@gmail.com
guilhermebla...@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
Re: [PHP-DEV] Annotations in PHP7
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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Thu, Feb 19, 2015 at 2:12 AM, François Laupretre franc...@php.net wrote: If I understand Dmitry correctly, this would be stored as the compiler internal representation of the 'new Entity(foo)' code, but this wouldn't be executed until an external mechanism decides to do so. So, this is PHP code and it is compiled and stored in memory besides the function opcodes, but not evaluated. Right. It's even not compiled into bytecode, just parsed into AST and then associated with function/class/property like doc-comment. You're right, it contains code. The key point is that this code will never be executed nor used in any way until an external mechanism decides to retrieve and evaluate it. That's metadata. Right again. Thanks. Dmirty. Regards François -Message d'origine- De : Crypto Compress [mailto:cryptocompr...@googlemail.com] Envoyé : mercredi 18 février 2015 23:11 À : PHP Developers Mailing List Objet : Re: [PHP-DEV] Annotations in PHP7 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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Annotations in PHP7
De : Benjamin Eberlei [mailto:kont...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Annotations in PHP7
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.
RE: [PHP-DEV] Annotations in PHP7
If I understand Dmitry correctly, this would be stored as the compiler internal representation of the 'new Entity(foo)' code, but this wouldn't be executed until an external mechanism decides to do so. So, this is PHP code and it is compiled and stored in memory besides the function opcodes, but not evaluated. You're right, it contains code. The key point is that this code will never be executed nor used in any way until an external mechanism decides to retrieve and evaluate it. That's metadata. Regards François -Message d'origine- De : Crypto Compress [mailto:cryptocompr...@googlemail.com] Envoyé : mercredi 18 février 2015 23:11 À : PHP Developers Mailing List Objet : Re: [PHP-DEV] Annotations in PHP7 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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Wed, Feb 18, 2015 at 12:51 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
François,
Doctrine relies on nested annotations for a variety of mapping information.
One example:
http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table
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 franc...@php.net
wrote:
Hi Alexander,
De : Alexander Lisachenko [mailto:lisachenko...@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: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Re: [PHP-DEV] Annotations in PHP7
On Tue, Feb 17, 2015 at 10:13 PM, Alexander Lisachenko lisachenko...@gmail.com wrote: 2015-02-17 19:25 GMT+03:00 Dmitry Stogov dmi...@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) 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.
Re: [PHP-DEV] Annotations in PHP7
On Tue, Feb 17, 2015 at 5:06 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 10:15 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 10:02 PM, Dmitry Stogov dmi...@zend.com wrote: On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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 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. 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.
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 10:15 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 10:02 PM, Dmitry Stogov dmi...@zend.com wrote: On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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 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. 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
Re: [PHP-DEV] Annotations in PHP7
2015-02-17 19:25 GMT+03:00 Dmitry Stogov dmi...@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.
RE: [PHP-DEV] Annotations in PHP7
Hi Alexander, De : Alexander Lisachenko [mailto:lisachenko...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
François, Doctrine relies on nested annotations for a variety of mapping information. One example: http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table []s, On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre franc...@php.net wrote: Hi Alexander, De : Alexander Lisachenko [mailto:lisachenko...@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: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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 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.
Re: [PHP-DEV] Annotations in PHP7
On Mon, 16 Feb 2015, Dmitry Stogov 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_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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 1:33 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 1:17 PM, Pavel Kouřil pajou...@gmail.com wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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. 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
Hi Nikita, On Tue, Feb 17, 2015 at 12:07 AM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 10:02 PM, Dmitry Stogov dmi...@zend.com wrote: On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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 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. 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
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 1:14 PM, Alexander Lisachenko lisachenko...@gmail.com wrote: 2015-02-16 15:12 GMT+03:00 Benjamin Eberlei kont...@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.
Re: [PHP-DEV] Annotations in PHP7
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. On Mon, Feb 16, 2015 at 3:43 PM, Cesar Rodas ce...@rodas.me wrote: On 16/02/15 13:40, Alexander Lisachenko wrote: 2015-02-16 15:31 GMT+03:00 Benjamin Eberlei kont...@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
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 1:17 PM, Pavel Kouřil pajou...@gmail.com wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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. 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
2015-02-16 15:31 GMT+03:00 Benjamin Eberlei kont...@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);
Re: [PHP-DEV] Annotations in PHP7
On 16/02/15 14:00, Dmitry Stogov wrote: 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. On Mon, Feb 16, 2015 at 3:43 PM, Cesar Rodas ce...@rodas.me wrote: On 16/02/15 13:40, Alexander Lisachenko wrote: 2015-02-16 15:31 GMT+03:00 Benjamin Eberlei kont...@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 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Annotations in PHP7
On 16/02/15 13:40, Alexander Lisachenko wrote: 2015-02-16 15:31 GMT+03:00 Benjamin Eberlei kont...@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 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Annotations in PHP7
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 den...@birkholz.biz wrote: Hi, Am 16.02.2015 um 12:07 schrieb Dmitry Stogov: HHVM already implemented similar concept http://docs.hhvm.com/manual/en/hack.attributes.php Why not borrow their syntax? Makes it easier to write stuff for both languages. Greets, Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
2015-02-16 15:12 GMT+03:00 Benjamin Eberlei kont...@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.
Re: [PHP-DEV] Annotations in PHP7
Hi, Am 16.02.2015 um 12:07 schrieb Dmitry Stogov: HHVM already implemented similar concept http://docs.hhvm.com/manual/en/hack.attributes.php Why not borrow their syntax? Makes it easier to write stuff for both languages. Greets, Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 10:57 PM, Derick Rethans der...@php.net wrote: On Mon, 16 Feb 2015, Dmitry Stogov 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_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 Why 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
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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 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. 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.
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 10:02 PM, Dmitry Stogov dmi...@zend.com wrote: On Mon, Feb 16, 2015 at 11:05 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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 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. 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
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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... 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.
Re: [PHP-DEV] Annotations in PHP7
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 kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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... 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.
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 12:42 PM, Dmitry Stogov dmi...@zend.com 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 kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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... 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.
Re: [PHP-DEV] Annotations in PHP7
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 kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:42 PM, Dmitry Stogov dmi...@zend.com 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 kont...@beberlei.de wrote: On Mon, Feb 16, 2015 at 12:07 PM, Dmitry Stogov dmi...@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_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... 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.
Re: [PHP-DEV] Annotations in PHP7
2015-02-16 14:42 GMT+03:00 Dmitry Stogov dmi...@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.
Re: [PHP-DEV] Annotations in PHP7
On Mon, Feb 16, 2015 at 1:10 PM, Alexander Lisachenko lisachenko...@gmail.com wrote: 2015-02-16 14:42 GMT+03:00 Dmitry Stogov dmi...@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?
