[RFC] [VOTE] PHP Attributes

8 years ago by Dmitry Stogov — view source

unread

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but it's not going to be the end of the world, if we decided to live with doc-comments only.

Thanks. Dmitry.

8 years ago by Fleshgrinder — view source

unread

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but it's not going to be the end of the world, if we decided to live with doc-comments only.

I hope it's going to be negative. The name is misleading and the AST
approach is not really useful in userland. :(

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Rasmus Schultz — view source

unread

A couple of quick comments - I'm sorry, I haven't had time to get them
in before now.

In my opinion, this is pretty bad, for one primary reason: these are
just names and values.

The advantage of this over parsing doc-blocks at run-time is pretty
limited - you can basically only guarantee syntax, you can't guarantee
anything about annotation types or the required arguments. Names and
values still need to be resolved at run-time - that seems really
brittle and redundant.

It's also not what the community wants - they want classes, e.g.
Doctrine annotations, the most popular choice:

https://github.com/doctrine/annotations

Or the project that I started (but no longer contribute to)

https://github.com/php-annotations/php-annotations/

We want classes for the same reason we don't want arrays with magical
key/value pairs - for example, so we can have static analysis,
inspections, auto-completion in IDEs, etc.

Annotations need more consideration for design time - run time
attributes, in my opinion, is not enough, and brings more net
complexity than actual annotations.

Because no behavior or coupling is defined, they won't behave well,
and the coupling will be unpredictable - we'll have lots of
frameworks, all doing things differently, which is the same situation
we have now.

In my opinion, if we need this functionality at all, we need real
annotations - not just new syntax for the data, but taking into
account the behavior.

I think annotations could be as simple as this:

https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46

In my opinion, this immediately solves a lot more problems with a lot
less effort (and fragmentation!) in userland.

It's immediately useful in any script, without having to select and
install a third-party Composer package or write complex code to
interpret the data.

As for "softer" and more complex rules, e.g. regarding the number of
allowed annotations of the same type, or the type of element they're
allowed on, etc. - it doesn't make much sense to try to implement or
enforce such rules, as these wouldn't be enforced until the moment you
actually query the annotations of an element anyhow. This could be
either left up to userland, e.g. consumers can easily check and
enforce constraints themselves using conditionals and exceptions.

As for single vs multiple annotations of the same type, I would ignore
this as well, for the same reason - even if you had an API like
getSingleAnnotation($type) this would have to return either an
instance of $type, or null, so the consumer is still left with the
burden of having to check the result, e.g. no more or less of a burden
than checking the number of returned annotations with count().

To summarize:

Annotations are immediately useful in any script
Annotations are coupled directly to classes
Classes is what most of us want in the end
Static type-checking is possible

I think that attributes are not the way to go about this - it's not
substantially better than the status quo and doesn't lead to anything
immediately useful to most developers without also
adopting/writing/learning a suitable framework.

Just my opinions.

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but it's not going to be the end of the world, if we decided to live with doc-comments only.

Thanks. Dmitry.

8 years ago by Benjamin Eberlei — view source

unread

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP extension,
but it's not going to be the end of the world, if we decided to live with
doc-comments only.

one question, Rasmus Schultz post goes into the similar direction.

Any reason why the annotations are only a numeric list and not key value
pairs? Key-Value would be much more powerful and address a ton of
objections for us (Doctrine).

In the current state it is pretty limited for more complex use-cases. I
don't want to fully embrace the complexities that Larry showed for Drupal
(in my opinion, too much annotations), but without key value pairs we could
only use this when we nested JSON into the attribute value strings for
example, not something I want to mix.

Thanks. Dmitry.

8 years ago by Dmitry Stogov — view source

unread

On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:
Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP
extension, but it's not going to be the end of the world, if we
decided to live with doc-comments only.
one question, Rasmus Schultz post goes into the similar direction.

Any reason why the annotations are only a numeric list and not key
value pairs? Key-Value would be much more powerful and address a ton
of objections for us (Doctrine).
Attributes their selves are key-values, only nested values are numeric,
but instead of simple values it's possible to use expression AST, that
is more powerful than key-values.

In the current state it is pretty limited for more complex use-cases.
I don't want to fully embrace the complexities that Larry showed for
Drupal (in my opinion, too much annotations), but without key value
pairs we could only use this when we nested JSON into the attribute
value strings for example, not something I want to mix.

The Drupal example implementation on top of attributes is included in RFC.

Thanks. Dmitry.

8 years ago by Larry Garfield — view source

unread

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP extension,
but it's not going to be the end of the world, if we decided to live with
doc-comments only.

one question, Rasmus Schultz post goes into the similar direction.

Any reason why the annotations are only a numeric list and not key value
pairs? Key-Value would be much more powerful and address a ton of
objections for us (Doctrine).

In the current state it is pretty limited for more complex use-cases. I
don't want to fully embrace the complexities that Larry showed for Drupal
(in my opinion, too much annotations), but without key value pairs we could
only use this when we nested JSON into the attribute value strings for
example, not something I want to mix.

I fully agree that Drupal's annotation use goes over-board at present.
:-) I used it as a real-world stress-case. However, even if we were to
scale back in Drupal the current Attributes proposal is too low-level to
be useful.

I do not have voting karma, but I would endorse voting NO on this RFC as is.

--Larry Garfield

8 years ago by Benjamin Eberlei — view source

unread

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP extension,
but it's not going to be the end of the world, if we decided to live with
doc-comments only.

Thanks. Dmitry.

I voted -1

Reasons: from a Doctrine Annotations maintainer perspective, either getting
a list (without keys) of strings back or ast\nodes are not enough or way
too advanced for our use-case. The middle ground is missing where a
<php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
nested array, that means getAttributes() does should not only return
"string" or ast\node as result for each attribute, to there should be a way
to get arrays back.

Example:

https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

greetings
Benjamin

8 years ago by Marco Pivetta — view source

unread

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP extension,
but it's not going to be the end of the world, if we decided to live with
doc-comments only.

Thanks. Dmitry.

I voted -1

Reasons: from a Doctrine Annotations maintainer perspective, either getting
a list (without keys) of strings back or ast\nodes are not enough or way
too advanced for our use-case. The middle ground is missing where a
<php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
nested array, that means getAttributes() does should not only return
"string" or ast\node as result for each attribute, to there should be a way
to get arrays back.

Example:

https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

greetings
Benjamin

Urgh, that is indeed quirky, and makes it unusable.

Is that an implementation or a spec issue? I know PHP 5.6+ allows array
constants, but I am not aware of whether that is in the specification.

Indeed, show-stopper here. I'll have to vote "-1" for now, and wait for a
version that either explicitly contains any constant expression or just
supports arrays as constants.

I'll also need to compile the branch and try it out myself before voting
further: my bad for being hasty.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

8 years ago by Rasmus Schultz — view source

unread

My problem with this PSR is you've created something that strongly
resembles function or constructor calls, but in reality is just
key/value pairs.

That's confusing in itself, but also puts an unnecessary burden on
consumers who have to figure out how to map this apparently
"something" to "something real" - since it really isn't anything other
than pretty syntax for arrays associated with source-code elements.

Did anybody look at my notes here?

https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46

I think this is much simpler and far more flexible - it lets you do
what you're proposing with attributes (by annotating with simple
arrays) and also lets you create annotation classes.

Would anyone care to comment?

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP extension,
but it's not going to be the end of the world, if we decided to live with
doc-comments only.

Thanks. Dmitry.

I voted -1

Reasons: from a Doctrine Annotations maintainer perspective, either getting
a list (without keys) of strings back or ast\nodes are not enough or way
too advanced for our use-case. The middle ground is missing where a
<php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
nested array, that means getAttributes() does should not only return
"string" or ast\node as result for each attribute, to there should be a way
to get arrays back.

Example:

https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

greetings
Benjamin

Urgh, that is indeed quirky, and makes it unusable.

Is that an implementation or a spec issue? I know PHP 5.6+ allows array
constants, but I am not aware of whether that is in the specification.

Indeed, show-stopper here. I'll have to vote "-1" for now, and wait for a
version that either explicitly contains any constant expression or just
supports arrays as constants.

I'll also need to compile the branch and try it out myself before voting
further: my bad for being hasty.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

8 years ago by Benjamin Eberlei — view source

unread

My problem with this PSR is you've created something that strongly
resembles function or constructor calls, but in reality is just
key/value pairs.

Its actually function calls, not constructors calls :-)

That's confusing in itself, but also puts an unnecessary burden on
consumers who have to figure out how to map this apparently
"something" to "something real" - since it really isn't anything other
than pretty syntax for arrays associated with source-code elements.

Did anybody look at my notes here?

https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46

I think this is much simpler and far more flexible - it lets you do
what you're proposing with attributes (by annotating with simple
arrays) and also lets you create annotation classes.

Would anyone care to comment?

What happens if you say <<$x>> and then call $reflection->getAttributes()
in your eample? what is $x?

That is the problem with immediately evaluating everything non "constant".
There is no context.

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP
extension,
but it's not going to be the end of the world, if we decided to live
with
doc-comments only.

Thanks. Dmitry.

I voted -1

Reasons: from a Doctrine Annotations maintainer perspective, either
getting
a list (without keys) of strings back or ast\nodes are not enough or way
too advanced for our use-case. The middle ground is missing where a
<php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
nested array, that means getAttributes() does should not only return
"string" or ast\node as result for each attribute, to there should be a
way
to get arrays back.

Example:

https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

greetings
Benjamin

Urgh, that is indeed quirky, and makes it unusable.

Is that an implementation or a spec issue? I know PHP 5.6+ allows array
constants, but I am not aware of whether that is in the specification.

Indeed, show-stopper here. I'll have to vote "-1" for now, and wait for a
version that either explicitly contains any constant expression or just
supports arrays as constants.

I'll also need to compile the branch and try it out myself before voting
further: my bad for being hasty.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

8 years ago by Rasmus Schultz — view source

unread

What happens if you say <<$x>> and then call $reflection->getAttributes() in your eample? what is $x?

That is the problem with immediately evaluating everything non "constant". There is no context.

There's is no context. Annotations should be context-free - that's by design.

There's also no $this, and no self:: or static:: either, because the
annotations are supposed to be context-free. They're meta-data, not
functions - you already have functions, interfaces, abstract methods
etc. for that.

Suppose you don't have an instance of a class yet, and you reflect and
try to get the value of something that requires context - it doesn't
exist yet. Then what? Obtaining the meta-data before you have an
instance is a common use-case, for example when generating schema from
table/column meta-data attached to entities, you don't have an
instance yet - you're inspecting the class, methods and properties,
not an object.

If you insist on putting something in annotations that requires
context, what you should put in there, is an anonymous function - e.g.
a function that expects the consumer to provide the context, such that
you're not dependent on some implied context, instead you're asking
for a specific context. Dependency injection - good stuff. There's an
example of that in my comment below the gist.

Though personally I would never, ever put functionality in an
annotation - it's a huge misunderstanding, in my opinion. If what you
wanted was executable functionality that requires a context, what you
really want is an interface that you can implement. Context requires a
contract.

Just my opinion, of course, and there's nothing stopping you from
using functions if that's your fancy. And it's much safer and
friendlier to readers, and static analysis tools, not to expect a
run-time context to always be established by the consumer.

Either way, the majority use-case is attaching meta-data to
classes/properties/methods - wanting to attach code and evaluate it at
run-time is a marginal use-case. Designing the whole thing for that
first, and sacrificing all the flexibility of the language itself by
inventing an entirely new concept, which is entirely dependent on
run-time interpretation, in my opinion, is just completely backwards,
when you can do something much, much simpler with far more freedom and
options and design-time safety.

My problem with this PSR is you've created something that strongly
resembles function or constructor calls, but in reality is just
key/value pairs.

Its actually function calls, not constructors calls :-)

That's confusing in itself, but also puts an unnecessary burden on
consumers who have to figure out how to map this apparently
"something" to "something real" - since it really isn't anything other
than pretty syntax for arrays associated with source-code elements.

Did anybody look at my notes here?

https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46

I think this is much simpler and far more flexible - it lets you do
what you're proposing with attributes (by annotating with simple
arrays) and also lets you create annotation classes.

Would anyone care to comment?

What happens if you say <<$x>> and then call $reflection->getAttributes() in
your eample? what is $x?

That is the problem with immediately evaluating everything non "constant".
There is no context.

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP
extension,
but it's not going to be the end of the world, if we decided to live
with
doc-comments only.

Thanks. Dmitry.

I voted -1

Reasons: from a Doctrine Annotations maintainer perspective, either
getting
a list (without keys) of strings back or ast\nodes are not enough or
way
too advanced for our use-case. The middle ground is missing where a
<php-constant> (Name borrowed from the RFC) can be an arbitrarily deep
nested array, that means getAttributes() does should not only return
"string" or ast\node as result for each attribute, to there should be a
way
to get arrays back.

Example:

https://gist.github.com/beberlei/18db9f7d5f6157b817348a58fa2aee25

greetings
Benjamin

Urgh, that is indeed quirky, and makes it unusable.

Is that an implementation or a spec issue? I know PHP 5.6+ allows array
constants, but I am not aware of whether that is in the specification.

Indeed, show-stopper here. I'll have to vote "-1" for now, and wait for
a
version that either explicitly contains any constant expression or just
supports arrays as constants.

I'll also need to compile the branch and try it out myself before voting
further: my bad for being hasty.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

8 years ago by Joe Watkins — view source

unread

Morning Dmitry,

I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include support for

AST, that's a completely different feature.

As it is, I have to vote yes in favour of AST, but it may be counted as

a vote in favour of attributes without AST ...

This doesn't seem right ... I don't want attributes without AST, and

there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson bjorn.x.larsson@telia.com
wrote:

Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP
extension, but it's not going to be the end of the world, if we decided to
live with doc-comments only.

Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?

The more I listen to arguments of adepts of existing PHP annotation
systems, the more I think, that "PHP attributes" is the right name for this
proposal.
This feature is not just for PHP annotation systems.

Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn

8 years ago by Rowan Collins — view source

unread

I would not vote in favour of a patch that does not include support for
AST, that's a completely different feature.

Arguably, with the right choice of extension methods, an implementation
requiring a single scalar could be extended to support arbitrary
expressions later, since "scalar" is a subset of "expression".

For instance, getAttributes() could provide a NULL value for any
attribute with a non-scalar argument, and a separate getAttributesAST()
could return an AST tree even if it consisted of a single constant.

I'm still not convinced the freedom of AST is justified though, as
opposed to a constant expression parsed according to standard PHP
semantics (e.g. an associative array) or some specific syntax
(effectively named parameters).

I'd personally be against both options in the current RFC, because I
think the language should be providing much more to make this useful.

Regards,

Rowan Collins
[IMSoP]

8 years ago by Dmitry Stogov — view source

unread

Hi Joe,

The sense in native support for AST is questionable.

On one hand this allows syntax verification.

On the other hand simple string may be parsed into AST with just one additional call to ast\compile_string().

Thanks. Dmitry.

8 years ago by Joe Watkins — view source

unread

Morning Dmitry,

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

You're not really suggesting that I write my tools in user land, are you ?
It's me, Joe :)

I only want attributes as they were originally proposed, and I can't vote
to reflect that.

As discussed in private, what I want is attributes, as originally proposed,
and a hookable compiler; Anything else is not good enough.

Cheers
Joe

Hi Joe,

The sense in native support for AST is questionable.

On one hand this allows syntax verification.

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

Thanks. Dmitry.

From: Joe Watkins pthreads@pthreads.org
Sent: Wednesday, May 11, 2016 7:46:09 AM
To: Björn Larsson
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning Dmitry,
I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include support
for AST, that's a completely different feature.
As it is, I have to vote yes in favour of AST, but it may be counted
as a vote in favour of attributes without AST ...
This doesn't seem right ... I don't want attributes without AST, and
there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson <bjorn.x.larsson@telia.com

wrote:

Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP
extension, but it's not going to be the end of the world, if we decided to
live with doc-comments only.

Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?

The more I listen to arguments of adepts of existing PHP annotation
systems, the more I think, that "PHP attributes" is the right name for this
proposal.
This feature is not just for PHP annotation systems.

Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn

8 years ago by Joe Watkins — view source

unread

Morning,

Because you have confused the vote by adding additional options very

late in the discussion, and because the majority are in favour of something
I think is harmful; I've had to vote no, on a feature that I want :s

Cheers
Joe

Morning Dmitry,

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

You're not really suggesting that I write my tools in user land, are you ?
It's me, Joe :)

I only want attributes as they were originally proposed, and I can't
vote to reflect that.

As discussed in private, what I want is attributes, as originally
proposed, and a hookable compiler; Anything else is not good enough.

Cheers
Joe
Hi Joe,

The sense in native support for AST is questionable.

On one hand this allows syntax verification.

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

Thanks. Dmitry.

From: Joe Watkins pthreads@pthreads.org
Sent: Wednesday, May 11, 2016 7:46:09 AM
To: Björn Larsson
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning Dmitry,
I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include support
for AST, that's a completely different feature.
As it is, I have to vote yes in favour of AST, but it may be counted
as a vote in favour of attributes without AST ...
This doesn't seem right ... I don't want attributes without AST, and
there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson <
bjorn.x.larsson@telia.com> wrote:

Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP
extension, but it's not going to be the end of the world, if we decided to
live with doc-comments only.

Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?

The more I listen to arguments of adepts of existing PHP annotation
systems, the more I think, that "PHP attributes" is the right name for this
proposal.
This feature is not just for PHP annotation systems.

Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn

8 years ago by Dmitry Stogov — view source

unread

Morning Dmitry,

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

You're not really suggesting that I write my tools in user land, are
you ? It's me, Joe :)ce

At first days of RFC discussion Sara pointed on over-design regarding AST.
I saw sense in here comments and updated RFC.

I only want attributes as they were originally proposed, and I can't
vote to reflect that.

As discussed in private, what I want is attributes, as originally
proposed, and a hookable compiler; Anything else is not good enough.

Personally, I'm for AST as well, but it's possible to get the same power
translating string values of attributes into AST in the hooks.

Thanks. Dmitry.

Cheers
Joe

On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:

Hi Joe,


The sense in native support for AST is questionable.


On one hand this allows syntax verification.


On the other hand simple string may be parsed into AST with just
one additional call to ast\compile_string().


Thanks. Dmitry.


------------------------------------------------------------------------
*From:* Joe Watkins <pthreads@pthreads.org
<mailto:pthreads@pthreads.org>>
*Sent:* Wednesday, May 11, 2016 7:46:09 AM
*To:* Björn Larsson
*Cc:* Dmitry Stogov; PHP internals
*Subject:* Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes
Morning Dmitry,

    I'm not really happy with the voting options here.

    I would not vote in favour of a patch that does not include
support for AST, that's a completely different feature.

    As it is, I have to vote yes in favour of AST, but it may be
counted as a vote in favour of attributes without AST ...

    This doesn't seem right ... I don't want attributes without
AST, and there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson
<bjorn.x.larsson@telia.com <mailto:bjorn.x.larsson@telia.com>> wrote:

    Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:



        

            Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

                Hi internals,


                I've started voting on "PHP Attributes" RFC.


                https://wiki.php.net/rfc/attributes


                In my opinion, "PHP Attributes" might be a smart
                tool for PHP extension, but it's not going to be
                the end of the world, if we decided to live with
                doc-comments only.


                Thanks. Dmitry.

            Thanks for the good work. Regarding naming, I googled
            "PHP attributes" vs "PHP annotations" and looking at the
            result, my view is that that Annotation is a better naming
            then Attributes. Any hope in changing it?


        The more I listen to arguments of adepts of existing PHP
        annotation systems, the more I think, that "PHP
        attributes" is the right name for this proposal.
        This feature is not just for PHP annotation systems.


    Thats a fair point, so Annotation it's not. Still, when I hear PHP
    attributes I associate it with class / function attributes. Maybe
    just a question getting used to the naming. Hm, wonder if PHP
    directives could have been an option?

    Regards //Björn



    -- 
    
    
    <http://www.php.net/unsub.php

8 years ago by Joe Watkins — view source

unread

Dmitry,

but it's possible to get the same power translating string values of
attributes into AST in the hooks.

Aware.

Enough of the complexity is already the responsibility of the consumer of
the attributes.

It's already possible to get strings (and so AST) from doc comments, we
don't need anything new if that's all you want to do.

Essentially, moving something from doc comments to <<here>> makes zero
sense to me.

Cheers
Joe

Morning Dmitry,

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

You're not really suggesting that I write my tools in user land, are you ?
It's me, Joe :)ce

At first days of RFC discussion Sara pointed on over-design regarding AST.
I saw sense in here comments and updated RFC.

I only want attributes as they were originally proposed, and I can't
vote to reflect that.

As discussed in private, what I want is attributes, as originally
proposed, and a hookable compiler; Anything else is not good enough.

Personally, I'm for AST as well, but it's possible to get the same power
translating string values of attributes into AST in the hooks.

Thanks. Dmitry.

Cheers
Joe
Hi Joe,

The sense in native support for AST is questionable.

On one hand this allows syntax verification.

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

Thanks. Dmitry.

From: Joe Watkins pthreads@pthreads.org
Sent: Wednesday, May 11, 2016 7:46:09 AM
To: Björn Larsson
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning Dmitry,
I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include support
for AST, that's a completely different feature.
As it is, I have to vote yes in favour of AST, but it may be counted
as a vote in favour of attributes without AST ...
This doesn't seem right ... I don't want attributes without AST, and
there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson <
bjorn.x.larsson@telia.com> wrote:

Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP
extension, but it's not going to be the end of the world, if we decided to
live with doc-comments only.

Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?

The more I listen to arguments of adepts of existing PHP annotation
systems, the more I think, that "PHP attributes" is the right name for this
proposal.
This feature is not just for PHP annotation systems.

Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn

--

To unsubscribe, visit: http://www.php.net/unsub.php
http://www.php.net/unsub.php

8 years ago by Dmitry Stogov — view source

unread

Dmitry,

but it's possible to get the same power translating string values of
attributes into AST in the hooks.

Aware.

Enough of the complexity is already the responsibility of the consumer
of the attributes.

It's already possible to get strings (and so AST) from doc comments,
we don't need anything new if that's all you want to do.

Essentially, moving something from doc comments to <<here>> makes zero
sense to me.

Except the fact, that doc-comment content don't have to conform to any
rules, and you have to parse it and extract the necessary part of meta
information every time you need it. It's not a big problem to do this
using Doctrine library, but how are you going to do this in a compiler hook?

Cheers
Joe

On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:

Morning Dmitry,

> On the other hand simple string may be parsed into AST with
just one additional call to ast\compile_string().

You're not really suggesting that I write my tools in user land,
are you ? It's me, Joe :)ce

At first days of RFC discussion Sara pointed on over-design
regarding AST.
I saw sense in here comments and updated RFC.

I *only* want attributes as they were originally proposed, and I
can't vote to reflect that.

As discussed in private, what I want is attributes, as originally
proposed, and a hookable compiler; Anything else is not good enough.

Personally, I'm for AST as well, but it's possible to get the same
power translating string values of attributes into AST in the hooks.

Thanks. Dmitry.

Cheers
Joe



On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov <dmitry@zend.com
<mailto:dmitry@zend.com>> wrote:

    Hi Joe,


    The sense in native support for AST is questionable.


    On one hand this allows syntax verification.


    On the other hand simple string may be parsed into AST with
    just one additional call to ast\compile_string().


    Thanks. Dmitry.


    ------------------------------------------------------------------------
    *From:* Joe Watkins <pthreads@pthreads.org
    <mailto:pthreads@pthreads.org>>
    *Sent:* Wednesday, May 11, 2016 7:46:09 AM
    *To:* Björn Larsson
    *Cc:* Dmitry Stogov; PHP internals
    *Subject:* Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes
    Morning Dmitry,

        I'm not really happy with the voting options here.

        I would not vote in favour of a patch that does not
    include support for AST, that's a completely different feature.

        As it is, I have to vote yes in favour of AST, but it may
    be counted as a vote in favour of attributes without AST ...

        This doesn't seem right ... I don't want attributes
    without AST, and there is no voting option to reflect that.

    Cheers
    Joe

    On Tue, May 10, 2016 at 11:09 PM, Björn Larsson
    <bjorn.x.larsson@telia.com
    <mailto:bjorn.x.larsson@telia.com>> wrote:

        Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:



            

                Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

                    Hi internals,


                    I've started voting on "PHP Attributes" RFC.


                    https://wiki.php.net/rfc/attributes


                    In my opinion, "PHP Attributes" might be a
                    smart tool for PHP extension, but it's not
                    going to be the end of the world, if we
                    decided to live with doc-comments only.


                    Thanks. Dmitry.

                Thanks for the good work. Regarding naming, I googled
                "PHP attributes" vs "PHP annotations" and looking
                at the
                result, my view is that that Annotation is a
                better naming
                then Attributes. Any hope in changing it?


            The more I listen to arguments of adepts of existing
            PHP annotation systems, the more I think, that "PHP
            attributes" is the right name for this proposal.
            This feature is not just for PHP annotation systems.


        Thats a fair point, so Annotation it's not. Still, when I
        hear PHP
        attributes I associate it with class / function
        attributes. Maybe
        just a question getting used to the naming. Hm, wonder if PHP
        directives could have been an option?

        Regards //Björn



        -- 
        
        To unsubscribe, visit:
        <http://www.php.net/unsub.php>http://www.php.net/unsub.php

8 years ago by Joe Watkins — view source

unread

Dmitry,

Except the fact, that doc-comment content don't have to conform to any
rules

Nor does an attributes value that is just a string, that isn't validated by
compiler ... it doesn't have to conform to any rules.

That's exactly what people are voting for though, that seems to be what
people want :s

I desperately do not want that. I don't see the remarkable difference
(although there is obviously difference) between attributes that are just
strings or constant values and doc comments.

and you have to parse it and extract the necessary part of meta
information every time you need it.

You know that's not really true, there are already hooks and mechanisms to
"compile" strings in doc comments, I used them literally yesterday ...

I used them in anticipation that we would get a superior solution some time
soon ... it now looks like we will not :(

I don't want to invent ways to parse code, or extract it from anywhere ...
we have a whole engine, an entire folder of code dedicated to that, it is
nonsensical not to utilize it.

Cheers
Joe

Dmitry,

but it's possible to get the same power translating string values of
attributes into AST in the hooks.

Aware.

Enough of the complexity is already the responsibility of the consumer of
the attributes.

It's already possible to get strings (and so AST) from doc comments, we
don't need anything new if that's all you want to do.

Essentially, moving something from doc comments to <<here>> makes zero
sense to me.

Except the fact, that doc-comment content don't have to conform to any
rules, and you have to parse it and extract the necessary part of meta
information every time you need it. It's not a big problem to do this using
Doctrine library, but how are you going to do this in a compiler hook?

Cheers
Joe
Morning Dmitry,

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

You're not really suggesting that I write my tools in user land, are you
? It's me, Joe :)ce

At first days of RFC discussion Sara pointed on over-design regarding AST.
I saw sense in here comments and updated RFC.

I only want attributes as they were originally proposed, and I can't
vote to reflect that.

As discussed in private, what I want is attributes, as originally
proposed, and a hookable compiler; Anything else is not good enough.

Personally, I'm for AST as well, but it's possible to get the same power
translating string values of attributes into AST in the hooks.

Thanks. Dmitry.

Cheers
Joe

On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov < dmitry@zend.com
dmitry@zend.com> wrote:
Hi Joe,

The sense in native support for AST is questionable.

On one hand this allows syntax verification.

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

Thanks. Dmitry.

From: Joe Watkins pthreads@pthreads.org
Sent: Wednesday, May 11, 2016 7:46:09 AM
To: Björn Larsson
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning Dmitry,
I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include support
for AST, that's a completely different feature.
As it is, I have to vote yes in favour of AST, but it may be counted
as a vote in favour of attributes without AST ...
This doesn't seem right ... I don't want attributes without AST, and
there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson <
bjorn.x.larsson@telia.com bjorn.x.larsson@telia.com> wrote:

Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes
https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP
extension, but it's not going to be the end of the world, if we decided to
live with doc-comments only.

Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?

The more I listen to arguments of adepts of existing PHP annotation
systems, the more I think, that "PHP attributes" is the right name for this
proposal.
This feature is not just for PHP annotation systems.

Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn

--

To unsubscribe, visit: http://www.php.net/unsub.php
http://www.php.net/unsub.php http://www.php.net/unsub.php

8 years ago by Benjamin Eberlei — view source

unread

Dmitry,

Except the fact, that doc-comment content don't have to conform to any
rules

Nor does an attributes value that is just a string, that isn't validated by
compiler ... it doesn't have to conform to any rules.

That's exactly what people are voting for though, that seems to be what
people want :s

I desperately do not want that. I don't see the remarkable difference
(although there is obviously difference) between attributes that are just
strings or constant values and doc comments.

and you have to parse it and extract the necessary part of meta
information every time you need it.

You know that's not really true, there are already hooks and mechanisms to
"compile" strings in doc comments, I used them literally yesterday ...

I used them in anticipation that we would get a superior solution some time
soon ... it now looks like we will not :(

I don't want to invent ways to parse code, or extract it from anywhere ...
we have a whole engine, an entire folder of code dedicated to that, it is
nonsensical not to utilize it.

Yes agree. I have to admit not to have read the RFC with my full attention
before, i would have spotted this otherwise.
I would really love to have attributes being arbitrarily nested arrays in
addition to just a list of strings and have the PHP parser
recognize, parse and validate that its correct.

<<ORM\Entity("User")>>
getAttributes() returns ["ORM\Entity" => "User"]

^ This is a very simple example from the RFC, but next to the very complex
Drupal example, there are rather "lightweight"
usages that make up the majority of Annotations in Docblocks right now. I
would like to see:

<<ORM\Entity("repositoryClass" => "MyApp\UserRepository", "table" =>
"users")>>
getAttributes() returns ["ORM\Entity" => ["repositoryClass" =>
"MyApp\UserRepository", "table" => "users"]]

The example from Drupal parsing the AST Nodes in the RFC nodes is extremely
complex code and would lead again to hundrets of slightly different
implementations
and no standardization around them. Essentially re-implementing the PHP
Parser in PHP on top of ast\nodes is not really what 80% of the users need
here, which is
arbitrary metadata (east way to represented in PHP as array).

Cheers
Joe
Dmitry,

but it's possible to get the same power translating string values of
attributes into AST in the hooks.

Aware.

Enough of the complexity is already the responsibility of the consumer of
the attributes.

It's already possible to get strings (and so AST) from doc comments, we
don't need anything new if that's all you want to do.

Essentially, moving something from doc comments to <<here>> makes zero
sense to me.

Except the fact, that doc-comment content don't have to conform to any
rules, and you have to parse it and extract the necessary part of meta
information every time you need it. It's not a big problem to do this
using
Doctrine library, but how are you going to do this in a compiler hook?

Cheers
Joe
Morning Dmitry,

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

You're not really suggesting that I write my tools in user land, are you
? It's me, Joe :)ce

At first days of RFC discussion Sara pointed on over-design regarding
AST.
I saw sense in here comments and updated RFC.

I only want attributes as they were originally proposed, and I can't
vote to reflect that.

As discussed in private, what I want is attributes, as originally
proposed, and a hookable compiler; Anything else is not good enough.

Personally, I'm for AST as well, but it's possible to get the same power
translating string values of attributes into AST in the hooks.

Thanks. Dmitry.

Cheers
Joe

On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov < dmitry@zend.com
dmitry@zend.com> wrote:
Hi Joe,

The sense in native support for AST is questionable.

On one hand this allows syntax verification.

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

Thanks. Dmitry.

From: Joe Watkins pthreads@pthreads.org
Sent: Wednesday, May 11, 2016 7:46:09 AM
To: Björn Larsson
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning Dmitry,
I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include support
for AST, that's a completely different feature.
As it is, I have to vote yes in favour of AST, but it may be
counted
as a vote in favour of attributes without AST ...
This doesn't seem right ... I don't want attributes without AST,
and

there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson <
bjorn.x.larsson@telia.com bjorn.x.larsson@telia.com> wrote:

Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes
https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP
extension, but it's not going to be the end of the world, if we
decided to
live with doc-comments only.

Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?

The more I listen to arguments of adepts of existing PHP annotation
systems, the more I think, that "PHP attributes" is the right name
for this
proposal.
This feature is not just for PHP annotation systems.

Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn

--

To unsubscribe, visit: http://www.php.net/unsub.php
http://www.php.net/unsub.php http://www.php.net/unsub.php

8 years ago by Dmitry Stogov — view source

unread

Dmitry,

Except the fact, that doc-comment content don't have to conform to
any rules

Nor does an attributes value that is just a string, that isn't
validated by compiler ... it doesn't have to conform to any rules.

That's exactly what people are voting for though, that seems to be
what people want

I think, different people expect very different functionality and many
just don't like to introduce replacement for existing doc-comments.
Probably the majority of voters against AST, just don't care about
applications of this feature (extensible compiler, meta-programming,
compile-time execution, etc)

I desperately do not want that. I don't see the remarkable difference
(although there is obviously difference) between attributes that are
just strings or constant values and doc comments.
The difference is small, but attributes standardize syntax and provide
standard storage with simple API.
In my view, better to get at least this than nothing.

and you have to parse it and extract the necessary part of meta
information every time you need it.

You know that's not really true, there are already hooks and
mechanisms to "compile" strings in doc comments, I used them literally
yesterday ...
I don't know about such hooks in the engine. do I miss something? :)

I used them in anticipation that we would get a superior solution some
time soon ... it now looks like we will not :(

I missed. do you speak about attributes with AST or doc-comments with
strings.

I don't want to invent ways to parse code, or extract it from anywhere
... we have a whole engine, an entire folder of code dedicated to
that, it is nonsensical not to utilize it.

You shouldn't worry about parsing PHP grammar in attribute strings, we
would just provide an API call in the engine that reuses zendparse() and
returns AST.
This would take just 10-20 C lines.

Thanks. Dmitry.

Cheers
Joe

On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:

Dmitry,

> but it's possible to get the same power translating string
values of attributes into AST in the hooks.

Aware.

Enough of the complexity is already the responsibility of the
consumer of the attributes.

It's already possible to get strings (and so AST) from doc
comments, we don't need anything new if that's all you want to do.

Essentially, moving something from doc comments to <<here>> makes
zero sense to me.

Except the fact, that doc-comment content don't have to conform to
any rules, and you have to parse it and extract the necessary part
of meta information every time you need it. It's not a big problem
to do this using Doctrine library, but how are you going to do
this in a compiler hook?

Cheers
Joe

On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov <dmitry@zend.com
<mailto:dmitry@zend.com>> wrote:

    Morning Dmitry,

    > On the other hand simple string may be parsed into AST
    with just one additional call to ast\compile_string().

    You're not really suggesting that I write my tools in user
    land, are you ? It's me, Joe :)ce

    At first days of RFC discussion Sara pointed on over-design
    regarding AST.
    I saw sense in here comments and updated RFC.

    I *only* want attributes as they were originally proposed,
    and I can't vote to reflect that.

    As discussed in private, what I want is attributes, as
    originally proposed, and a hookable compiler; Anything else
    is not good enough.

    Personally, I'm for AST as well, but it's possible to get the
    same power translating string values of attributes into AST
    in the hooks.

    Thanks. Dmitry.

    Cheers
    Joe



    On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov
    <dmitry@zend.com <mailto:dmitry@zend.com>> wrote:

        Hi Joe,


        The sense in native support for AST is questionable.


        On one hand this allows syntax verification.


        On the other hand simple string may be parsed into AST
        with just one additional call to ast\compile_string().


        Thanks. Dmitry.


        ------------------------------------------------------------------------
        *From:* Joe Watkins <pthreads@pthreads.org
        <mailto:pthreads@pthreads.org>>
        *Sent:* Wednesday, May 11, 2016 7:46:09 AM
        *To:* Björn Larsson
        *Cc:* Dmitry Stogov; PHP internals
        *Subject:* Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes
        Morning Dmitry,

            I'm not really happy with the voting options here.

            I would not vote in favour of a patch that does not
        include support for AST, that's a completely different
        feature.

            As it is, I have to vote yes in favour of AST, but
        it may be counted as a vote in favour of attributes
        without AST ...

            This doesn't seem right ... I don't want attributes
        without AST, and there is no voting option to reflect that.

        Cheers
        Joe

        On Tue, May 10, 2016 at 11:09 PM, Björn Larsson
        <bjorn.x.larsson@telia.com
        <mailto:bjorn.x.larsson@telia.com>> wrote:

            Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:



                

                    Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

                        Hi internals,


                        I've started voting on "PHP Attributes" RFC.


                        https://wiki.php.net/rfc/attributes


                        In my opinion, "PHP Attributes" might be
                        a smart tool for PHP extension, but it's
                        not going to be the end of the world, if
                        we decided to live with doc-comments only.


                        Thanks. Dmitry.

                    Thanks for the good work. Regarding naming,
                    I googled
                    "PHP attributes" vs "PHP annotations" and
                    looking at the
                    result, my view is that that Annotation is a
                    better naming
                    then Attributes. Any hope in changing it?


                The more I listen to arguments of adepts of
                existing PHP annotation systems, the more I
                think, that "PHP attributes" is the right name
                for this proposal.
                This feature is not just for PHP annotation systems.


            Thats a fair point, so Annotation it's not. Still,
            when I hear PHP
            attributes I associate it with class / function
            attributes. Maybe
            just a question getting used to the naming. Hm,
            wonder if PHP
            directives could have been an option?

            Regards //Björn



            -- 
            
            To unsubscribe, visit:
            <http://www.php.net/unsub.php>http://www.php.net/unsub.php

8 years ago by Joe Watkins — view source

unread

Dmitry,

The difference is small, but attributes standardize syntax and provide
standard storage with simple API.

It's too small. If we go ahead now and introduce constants or strings as
the only supported form of attribute, we will never get anything more than
that.

I don't know about such hooks in the engine. do I miss something? :)

There's no zend_set_magic_comments hook :D

There's mechanisms like op array ctor, reserved space, and overloading all
kinds of ways ... it's doable ... you already know it is ...

I missed. do you speak about attributes with AST or doc-comments with
strings.

I'm saying I decided the write some extension code that "parses" doc
comments, in anticipation that we would eventually get ast attributes ...

Cheers
Joe

Dmitry,

Except the fact, that doc-comment content don't have to conform to any
rules

Nor does an attributes value that is just a string, that isn't validated
by compiler ... it doesn't have to conform to any rules.

That's exactly what people are voting for though, that seems to be what
people want

I think, different people expect very different functionality and many
just don't like to introduce replacement for existing doc-comments.
Probably the majority of voters against AST, just don't care about
applications of this feature (extensible compiler, meta-programming,
compile-time execution, etc)

I desperately do not want that. I don't see the remarkable difference
(although there is obviously difference) between attributes that are just
strings or constant values and doc comments.

The difference is small, but attributes standardize syntax and provide
standard storage with simple API.
In my view, better to get at least this than nothing.

and you have to parse it and extract the necessary part of meta
information every time you need it.

You know that's not really true, there are already hooks and mechanisms to
"compile" strings in doc comments, I used them literally yesterday ...

I don't know about such hooks in the engine. do I miss something? :)

I used them in anticipation that we would get a superior solution some
time soon ... it now looks like we will not :(

I missed. do you speak about attributes with AST or doc-comments with
strings.

I don't want to invent ways to parse code, or extract it from anywhere ...
we have a whole engine, an entire folder of code dedicated to that, it is
nonsensical not to utilize it.

You shouldn't worry about parsing PHP grammar in attribute strings, we
would just provide an API call in the engine that reuses zendparse() and
returns AST.
This would take just 10-20 C lines.

Thanks. Dmitry.

Cheers
Joe
Dmitry,

but it's possible to get the same power translating string values of
attributes into AST in the hooks.

Aware.

Enough of the complexity is already the responsibility of the consumer of
the attributes.

It's already possible to get strings (and so AST) from doc comments, we
don't need anything new if that's all you want to do.

Essentially, moving something from doc comments to <<here>> makes zero
sense to me.

Except the fact, that doc-comment content don't have to conform to any
rules, and you have to parse it and extract the necessary part of meta
information every time you need it. It's not a big problem to do this using
Doctrine library, but how are you going to do this in a compiler hook?

Cheers
Joe

On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov < dmitry@zend.com
dmitry@zend.com> wrote:
Morning Dmitry,

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

You're not really suggesting that I write my tools in user land, are you
? It's me, Joe :)ce

At first days of RFC discussion Sara pointed on over-design regarding
AST.
I saw sense in here comments and updated RFC.

I only want attributes as they were originally proposed, and I can't
vote to reflect that.

As discussed in private, what I want is attributes, as originally
proposed, and a hookable compiler; Anything else is not good enough.

Personally, I'm for AST as well, but it's possible to get the same power
translating string values of attributes into AST in the hooks.

Thanks. Dmitry.

Cheers
Joe

On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov < dmitry@zend.com
dmitry@zend.com> wrote:
Hi Joe,

The sense in native support for AST is questionable.

On one hand this allows syntax verification.

On the other hand simple string may be parsed into AST with just one
additional call to ast\compile_string().

Thanks. Dmitry.

From: Joe Watkins < pthreads@pthreads.org pthreads@pthreads.org>
Sent: Wednesday, May 11, 2016 7:46:09 AM
To: Björn Larsson
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning Dmitry,
I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include support
for AST, that's a completely different feature.
As it is, I have to vote yes in favour of AST, but it may be
counted as a vote in favour of attributes without AST ...
This doesn't seem right ... I don't want attributes without AST,
and there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson <
bjorn.x.larsson@telia.com bjorn.x.larsson@telia.com> wrote:

Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,

I've started voting on "PHP Attributes" RFC.

https://wiki.php.net/rfc/attributes
https://wiki.php.net/rfc/attributes

In my opinion, "PHP Attributes" might be a smart tool for PHP
extension, but it's not going to be the end of the world, if we decided to
live with doc-comments only.

Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?

The more I listen to arguments of adepts of existing PHP annotation
systems, the more I think, that "PHP attributes" is the right name for this
proposal.
This feature is not just for PHP annotation systems.

Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn

--

To unsubscribe, visit: http://www.php.net/unsub.php
http://www.php.net/unsub.php http://www.php.net/unsub.php

8 years ago by Stanislav Malyshev — view source

unread

Hi!

Personally, I'm for AST as well, but it's possible to get the same power
translating string values of attributes into AST in the hooks.

Extending this, it's also possible to get the same power just extracting
phpdocs and applying AST to them.

Stas Malyshev
smalyshev@gmail.com

8 years ago by Dmitry Stogov — view source

unread

Hi!

Personally, I'm for AST as well, but it's possible to get the same power
translating string values of attributes into AST in the hooks.
Extending this, it's also possible to get the same power just extracting
phpdocs and applying AST to them.
In general yes, but we don't have grammar for doc-comments, and even
extracting general string value may be not trivial.

/**

Adds two positive numbers
@ensures $x + $y >=
```
             0
```
// support for multi-line attribute values?
@on_enter @enter_function(FUNCTION);
'@' sign before enter_function() is a silence operator.
*/
function add($x, $y) {
return $x + $y;
}

[RFC] [VOTE] PHP Attributes

Regards,

Extending this, it's also possible to get the same power just extracting phpdocs and applying AST to them.

Extending this, it's also possible to get the same power just extracting
phpdocs and applying AST to them.