Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Larry Garfield]

On 05/10/2016 03:48 PM, Benjamin Eberlei wrote:

On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov  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).

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Rasmus Schultz]

> 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.


On Thu, May 12, 2016 at 9:27 PM, Benjamin Eberlei  wrote:
>
>
> On Thu, May 12, 2016 at 9:02 PM, Rasmus Schultz  wrote:
>>
>> 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.
>>
>>
>>
>> On Thu, May 12, 2016 at 4:53 PM, Marco Pivetta  wrote:
>> > On 12 May 2016 at 16:29, Benjamin Eberlei  wrote:
>> >
>> >> On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov  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.
>> >> >
>> >> >
>> >> > 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
>> >>  (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 

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Benjamin Eberlei]

On Thu, May 12, 2016 at 9:02 PM, Rasmus Schultz  wrote:

> 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.

>
>
> On Thu, May 12, 2016 at 4:53 PM, Marco Pivetta  wrote:
> > On 12 May 2016 at 16:29, Benjamin Eberlei  wrote:
> >
> >> On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov  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.
> >> >
> >> >
> >> > 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
> >>  (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/
>

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Rasmus Schultz]

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?


On Thu, May 12, 2016 at 4:53 PM, Marco Pivetta  wrote:
> On 12 May 2016 at 16:29, Benjamin Eberlei  wrote:
>
>> On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov  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.
>> >
>> >
>> > 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
>>  (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/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Marco Pivetta]

On 12 May 2016 at 16:29, Benjamin Eberlei  wrote:

> On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov  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.
> >
> >
> > 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
>  (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/

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Benjamin Eberlei]

On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov  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.
>
>
> 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
 (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

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Rowan Collins]

On 11/05/2016 05:46, Joe Watkins wrote:

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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: outRe: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Joe Watkins]

t;
>>>
>>> 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 < <dmi...@zend.com>
>>> dmi...@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 < <pthre...@pthreads.org>pthre...@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.lars...@telia.com>bjorn.x.lars...@telia.com> wrote:
>>>>
>>>>> Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 05/11/2016 12:29 AM, Björn Larsson wrote:
>>>>>>
>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>> To unsubscribe, visit: <http://www.php.net/unsub.php>
>>>>> <http://www.php.net/unsub.php>http://www.php.net/unsub.php
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>

[PHP-DEV] outRe: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 11:42 AM, Joe Watkins wrote:

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 <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:




On 05/11/2016 09:57 AM, Joe Watkins 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 <> 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 <dmi...@zend.com
<mailto:dmi...@zend.com>> wrote:



On 05/11/2016 09:02 AM, Joe Watkins 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
<dmi...@zend.com <mailto:dmi...@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 <pthre...@pthreads.org
<mailto:pthre...@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

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Benjamin Eberlei]

ating string values of attributes into AST in the hooks.
> >>
> >> Thanks. Dmitry.
> >>
> >>
> >>
> >> Cheers
> >> Joe
> >>
> >>
> >>
> >> On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov < <dmi...@zend.com>
> >> dmi...@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 <pthre...@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.lars...@telia.com>bjorn.x.lars...@telia.com> wrote:
> >>>
> >>>> Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 05/11/2016 12:29 AM, Björn Larsson wrote:
> >>>>>
> >>>>>> 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
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> PHP Internals - PHP Runtime Development Mailing List
> >>>> To unsubscribe, visit: <http://www.php.net/unsub.php>
> >>>> <http://www.php.net/unsub.php>http://www.php.net/unsub.php
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
>

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Joe Watkins]

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



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

>
>
> On 05/11/2016 09:57 AM, Joe Watkins 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 <> 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 <dmi...@zend.com> wrote:
>
>>
>>
>> On 05/11/2016 09:02 AM, Joe Watkins 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 < <dmi...@zend.com>
>> dmi...@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 <pthre...@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.lars...@telia.com>bjorn.x.lars...@telia.com> wrote:
>>>
>>>> Den 2

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 10:27 AM, Stanislav Malyshev wrote:

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;
}


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Stanislav Malyshev]

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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 09:57 AM, Joe Watkins 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 <> 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 <dmi...@zend.com 
<mailto:dmi...@zend.com>> wrote:




On 05/11/2016 09:02 AM, Joe Watkins 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 <dmi...@zend.com
<mailto:dmi...@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 <pthre...@pthreads.org
<mailto:pthre...@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.lars...@telia.com
<mailto:bjorn.x.lars...@telia.com>> wrote:

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



On 05/11/2016 12:29 AM, Björn Larsson wrote:

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



-- 
PHP Internals - PHP Runtime Development Mailing List

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

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Joe Watkins]

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 <> makes zero
sense to me.

Cheers
Joe

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

>
>
> On 05/11/2016 09:02 AM, Joe Watkins 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 <dmi...@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 <pthre...@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.lars...@telia.com> wrote:
>>
>>> Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:
>>>
>>>>
>>>>
>>>> On 05/11/2016 12:29 AM, Björn Larsson wrote:
>>>>
>>>>> 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
>>>
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: <http://www.php.net/unsub.php>
>>> http://www.php.net/unsub.php
>>>
>>>
>>
>
>

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 09:02 AM, Joe Watkins 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 <dmi...@zend.com 
<mailto:dmi...@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 <pthre...@pthreads.org
<mailto:pthre...@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.lars...@telia.com <mailto:bjorn.x.lars...@telia.com>> wrote:

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



On 05/11/2016 12:29 AM, Björn Larsson wrote:

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



-- 
PHP Internals - PHP Runtime Development Mailing List

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

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Joe Watkins]

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

On Wed, May 11, 2016 at 7:02 AM, Joe Watkins <pthre...@pthreads.org> 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 :)
>
> 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
>
>
>
> On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov <dmi...@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 <pthre...@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.lars...@telia.com> wrote:
>>
>>> Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:
>>>
>>>>
>>>>
>>>> On 05/11/2016 12:29 AM, Björn Larsson wrote:
>>>>
>>>>> 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
>>>
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Joe Watkins]

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



On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov <dmi...@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 <pthre...@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.lars...@telia.com
> > wrote:
>
>> Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:
>>
>>>
>>>
>>> On 05/11/2016 12:29 AM, Björn Larsson wrote:
>>>
>>>> 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
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

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 <pthre...@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.lars...@telia.com<mailto:bjorn.x.lars...@telia.com>> wrote:
Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:


On 05/11/2016 12:29 AM, Björn Larsson wrote:
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



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Joe Watkins]

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 
wrote:

> Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:
>
>>
>>
>> On 05/11/2016 12:29 AM, Björn Larsson wrote:
>>
>>> 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
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Björn Larsson]

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



On 05/11/2016 12:29 AM, Björn Larsson wrote:

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 12:29 AM, Björn Larsson wrote:

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.



Regards //Björn Larsson




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Björn Larsson]

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?

Regards //Björn Larsson


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/10/2016 11:48 PM, Benjamin Eberlei wrote:



On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov > 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.

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Benjamin Eberlei]

On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov  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).

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.
>

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Rasmus Schultz]

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.


On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov  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.
>
>
> Thanks. Dmitry.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Fleshgrinder]

On 5/10/2016 8:29 PM, Dmitry Stogov 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.
> 

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



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] [RFC] [VOTE] PHP Attributes

[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.