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

On 4/25/2016 10:31 AM, Dmitry Stogov wrote: > completely disagree. > Each value in multi-value attribute may have its own meaning. e.g. > <> > That is a different example but I think that I misinterpreted it anyways. <> function foo() {} I thought that the above would result in the followin

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

Hi! > You may try to replace attribute syntax with @attr(...) (without > semicolon) into our PHP parser. > Note that we have LALR grammar + restrictions caused by semantic actions. > If you are able to do this, I'll add it into the RFC as an option. I'll try if I have time soon. -- Stas Malyshe

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

On 4/25/2016 10:04 AM, Dmitry Stogov wrote: > > > On 04/24/2016 11:24 AM, Fleshgrinder wrote: >> The invariant could also be added as an additional branch to the class >> instead of a method, since it would not work like a method. >> >>class A {} invariant {} >> >>function f() {} require

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

On 27 April 2016 at 03:27, Dmitry Stogov wrote: > > > On 04/27/2016 08:25 AM, Pierrick Charron wrote: > > Hi all, > > First of all thanks dmitry for your great work and for bringing the RFC > back to life. > > I think it would be great to allow users to define their own annotations > and give the

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

On 04/27/2016 08:25 AM, Pierrick Charron wrote: Hi all, First of all thanks dmitry for your great work and for bringing the RFC back to life. I think it would be great to allow users to define their own annotations and give them some structure (what the annotation is made of). For example

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

Hi all, First of all thanks dmitry for your great work and for bringing the RFC back to life. I think it would be great to allow users to define their own annotations and give them some structure (what the annotation is made of). For example let's say I apply an annotation to define that a proper

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

__ >> From: Dominic Grostate >> Sent: Tuesday, April 26, 2016 19:43 >> To: Dmitry Stogov >> Cc: rowan.coll...@gmail.com; PHP internals; Stanislav Malyshev >> Subject: Re: [PHP-DEV] [RFC] PHP Attributes >> >> >> Why not like C#? >

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

On 4/25/2016 10:31 AM, Dmitry Stogov wrote: > > > On 04/23/2016 06:29 PM, Fleshgrinder wrote: >> +1 for the basic idea, however, I have various remarks. >> >> The RFC text is hard to read and contains many grammatical mistakes. How >> could one help you here? > I would need a co-author :) > I w

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

o: Dmitry Stogov > Cc: rowan.coll...@gmail.com; PHP internals; Stanislav Malyshev > Subject: Re: [PHP-DEV] [RFC] PHP Attributes > > > Why not like C#? > > [Description("My Function")] > function my_function() > {} > > Without the semicolon, this wouldn't

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

Just because HHVM is closer to PHP than C#. From: Dominic Grostate Sent: Tuesday, April 26, 2016 19:43 To: Dmitry Stogov Cc: rowan.coll...@gmail.com; PHP internals; Stanislav Malyshev Subject: Re: [PHP-DEV] [RFC] PHP Attributes Why not like C#? [Description

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

Why not like C#? [Description("My Function")] function my_function() {} Without the semicolon, this wouldn't be valid in any other context. On 26 Apr 2016 8:41 a.m., "Dmitry Stogov" wrote: On 04/25/2016 11:20 PM, Stanislav Malyshev wrote: > Hi! > > No, but this is valid: >> >> @atrr(); funct

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

On 04/25/2016 11:20 PM, Stanislav Malyshev wrote: Hi! No, but this is valid: @atrr(); function foo() { ... } That's perhaps a little too close for comfort...? That's different syntax. If you put ; in the middle of statement, it can change - "$c = $a + $b;" is not the same as "$c = $a; + $b

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

On 4/25/2016 10:04 PM, Rowan Collins wrote: > On 25/04/2016 19:37, Stanislav Malyshev wrote: >> Hi! >> >>> @attr() - is a valid "silenced" call to function named "attr". >>> This syntax can't be reused. >> Not valid if it's in the middle of class definition, and not valid in >> form of: >> >> @attr

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

Hi! > No, but this is valid: > > @atrr(); function foo() { ... } > > That's perhaps a little too close for comfort...? That's different syntax. If you put ; in the middle of statement, it can change - "$c = $a + $b;" is not the same as "$c = $a; + $b;" - but nobody thinks + can not be used beca

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

On 25/04/2016 19:37, Stanislav Malyshev wrote: Hi! @attr() - is a valid "silenced" call to function named "attr". This syntax can't be reused. Not valid if it's in the middle of class definition, and not valid in form of: @attr() function foo() { ... } This is not a valid PHP syntax now. So

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

Check here to see what we did for php-annotations: https://github.com/php-annotations/php-annotations/blob/master/docs/CustomAnnotations.rst#usageannotation It's somewhat similar to how C# does it, and it has worked quite nicely. On Mon, Apr 25, 2016 at 8:40 PM, Stanislav Malyshev wrote: > Hi

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

Hi! > a class/property/method that has annotations, it NOT inherit > annotations/attributes by default. However, by adding an annotation of > > <<__inherit>> > > (Or some other internal-reserved keyword, I don't have strong feelings > on what it is) then the engine will automatically give you al

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

Hi! > @attr() - is a valid "silenced" call to function named "attr". > This syntax can't be reused. Not valid if it's in the middle of class definition, and not valid in form of: @attr() function foo() { ... } This is not a valid PHP syntax now. So I'm not sure why it can't be used. << is an op

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

Hi! > The proposed by you "@..." syntax just won't fit into PHP grammar, > because @ used as silence operator. Not sure why it is a problem more than << and >> being shift operators. Since you said it can't be applied to anonymous functions/classes anyway, parser with the help of AST should be ab

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

On Mon, Apr 25, 2016 at 7:11 PM, Rowan Collins wrote: > guilhermebla...@gmail.com wrote on 25/04/2016 15:22: > >> Another thing that looks odd to me i that every time you call new >> ReflectionClass, a new reflection_object gets created. >> Isn't there a way to get this "cached" somehow in zend_c

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

guilhermebla...@gmail.com wrote on 25/04/2016 15:22: Another thing that looks odd to me i that every time you call new ReflectionClass, a new reflection_object gets created. Isn't there a way to get this "cached" somehow in zend_class_entry? I recently came upon a package that exists solely to

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

On Mon, Apr 25, 2016 at 6:49 PM, Larry Garfield wrote: > On 04/25/2016 10:20 AM, Dmitry Stogov wrote: > >> >> This leads to some serious copy/paste, highly error prone... =( >>> >> >> If we had a theoretical approach for attribute inheritance, I would >> implement it. >> But I wouldn't invite any

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

On 04/25/2016 10:20 AM, Dmitry Stogov wrote: This leads to some serious copy/paste, highly error prone... =( If we had a theoretical approach for attribute inheritance, I would implement it. But I wouldn't invite any theory, because anyone is going to depend on use-case. Realistically, I

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

internals Subject: Re: [PHP-DEV] [RFC] PHP Attributes Another thing that looks odd to me i that every time you call new ReflectionClass, a new reflection_object gets created. Isn't there a way to get this "cached" somehow in zend_class_entry? On Mon, Apr 25, 2016 at 10:11 AM

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

On 04/25/2016 05:11 PM, guilhermebla...@gmail.com wrote: On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov > wrote: On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote: On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov

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

Another thing that looks odd to me i that every time you call new ReflectionClass, a new reflection_object gets created. Isn't there a way to get this "cached" somehow in zend_class_entry? On Mon, Apr 25, 2016 at 10:11 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > > > On Mon

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

On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov wrote: > > > On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote: > > > On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote: > >> >> >> On 04/22/2016 04:05 AM, >> guilhermebla...@gmail.com wrote: >> >> Hi Dmitry, >> >> As a previous suggester

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

Dan Ackroyd wrote on 24/04/2016 21:45: The point I was trying to make is that it explicitly says that "this is a userland attribute", rather than using the generic <<...>> syntax, which we might want to use for non-userland attributes at some point. I think framing the problem as "engine vs use

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

On 04/25/2016 02:28 PM, Joe Watkins wrote: Morning internals, This morning I attempted to prototype a dbc extension. In my opinion, the patch, or internals, are not fit for the intended purpose. At the moment, the *only* way to perform meta programming is going to be in userla

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

On 25/04/16 09:42, Dmitry Stogov wrote: > I know, any syntax is going to be loved by ones and hated by others... > It's not possible to satisfy everyone. If one takes a step back, current well used annotation IS provided but not cleanly documented in the docbloc material that is a major element of

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

Morning internals, This morning I attempted to prototype a dbc extension. In my opinion, the patch, or internals, are not fit for the intended purpose. At the moment, the *only* way to perform meta programming is going to be in userland. This is going to make it prohibitively slow, a

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

On 04/25/2016 12:44 PM, Pierre Joye wrote: hi Dmitry, Awesome work! Thanks. I do like you keep what was discussed last time. Make the basics available and leave the rest to the applications (doctrine or other). I feel too that how the apps will interact with may need some more discussions bu

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

hi Dmitry, Awesome work! Thanks. I do like you keep what was discussed last time. Make the basics available and leave the rest to the applications (doctrine or other). I feel too that how the apps will interact with may need some more discussions but other commented on it so I won't interfer her

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

On 04/24/2016 02:09 AM, Thomas Bley wrote: The <<>> syntax comes with the problem that previous versions cannot ignore it on parsing. So poeple write new frameworks for 7.0 which cannot be parsed in 5.x, then they write new frameworks for 7.1 which cannot be parsed with 7.0 and 5.x and so on.

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

On 04/25/2016 06:23 AM, Stanislav Malyshev wrote: Hi! https://wiki.php.net/rfc/attributes I've read the proposal and I like the idea of reviving the attributes idea and the simplicity of the approach. I have the following questions for it: - Namespacing. Since the attribute names are not p

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

> > I think that the Hack name attributes is unintelligible and annotations >> would be much clearer to any audience. Simply because the name is very >> well known. >> > > Different languages names this differently. > I may add an additional voting question - "annotation vs attributes?". The desc

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

On 04/24/2016 07:57 PM, Levi Morrison wrote: On Sun, Apr 24, 2016 at 10:03 AM, Dan Ackroyd wrote: On 21 April 2016 at 22:13, Dmitry Stogov wrote: Hi, I would like to present an RFC proposing support for native annotation. Hi Dmitry, Although everyone will have an opinion about the synt

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

On 04/24/2016 07:03 PM, Dan Ackroyd wrote: On 21 April 2016 at 22:13, Dmitry Stogov wrote: Hi, I would like to present an RFC proposing support for native annotation. Hi Dmitry, Although everyone will have an opinion about the syntax, I think there is one criticism that should be thought

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

On 04/24/2016 12:34 AM, Yasuo Ohgaki wrote: Hi Dimitry, On Fri, Apr 22, 2016 at 6:13 AM, Dmitry Stogov wrote: I would like to present an RFC proposing support for native annotation. The naming, syntax and behavior are mostly influenced by HHVM Hack, but not exactly the same. The most inte

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

On 04/23/2016 06:29 PM, Fleshgrinder wrote: +1 for the basic idea, however, I have various remarks. The RFC text is hard to read and contains many grammatical mistakes. How could one help you here? I would need a co-author :) I think that the Hack name attributes is unintelligible and anno

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

On 04/24/2016 05:02 PM, Thomas Punt wrote: Hi! From: dmi...@zend.com On 04/22/2016 02:46 PM, Thomas Punt wrote: Hi Dmitry! Just a couple of comments on this: 1. I'd definitely reuse the php-ast extension for parsing the code into an AST. It performs a number of transformations on PHP's und

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

On 04/24/2016 03:33 PM, Fleshgrinder wrote: I am not arguing against the RFC nor the feature itself, on the contrary, I like it. I just do not like certain aspects and design decisions of it; that is all. Configuration and AOP are the best usecases for annotations and those should be stressed

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

On 04/24/2016 11:24 AM, Fleshgrinder wrote: The invariant could also be added as an additional branch to the class instead of a method, since it would not work like a method. class A {} invariant {} function f() {} require {} ensure {} This would also align nicely with closures and ano

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

On 04/22/2016 06:56 PM, Larry Garfield wrote: On 4/22/16 10:39 AM, guilhermebla...@gmail.com wrote: On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote: 3- Did you put any thought on inheritance? What I mentioned in comment #1 is even smaller than what you implemented in RFC. Assuming

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

On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote: On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov > wrote: On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote: Hi Dmitry, As a previous suggester of metad

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

Hi! > https://wiki.php.net/rfc/attributes I've read the proposal and I like the idea of reviving the attributes idea and the simplicity of the approach. I have the following questions for it: - Namespacing. Since the attribute names are not processed in any way according to spec, it may be rath

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

Hey Levi, TL:DR, if we can reserve some syntax for annotations that will be used by the PHP Engine, that would cover my concern. On 24 April 2016 at 17:57, Levi Morrison wrote: > isn't `@attr()` 100% valid user-land code today that can precede Er, yes it is! I didn't put too much thought the

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

On 4/24/2016 6:57 PM, Levi Morrison wrote: > Genuine question[1]: how is @attr() different than `<>`? Also, > isn't `@attr()` 100% valid user-land code today that can precede > function or constant declarations? > > [1] I don't like that I have to make that explicit but it is what it is. > ROF

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

On Sun, Apr 24, 2016 at 10:03 AM, Dan Ackroyd wrote: > On 21 April 2016 at 22:13, Dmitry Stogov wrote: >> Hi, >> >> >> I would like to present an RFC proposing support for native annotation. >> > > Hi Dmitry, > > Although everyone will have an opinion about the syntax, I think there > is one crit

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

On 21 April 2016 at 22:13, Dmitry Stogov wrote: > Hi, > > > I would like to present an RFC proposing support for native annotation. > Hi Dmitry, Although everyone will have an opinion about the syntax, I think there is one criticism that should be thought about; the chosen syntax isn't future ex

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

I think it's much less work to parse <<>> as comments in 7.0 instead of having every framework releasing and supporting two packages. In the past, frameworks released new major versions to use new PHP features, but this came with a lot of incompatibilities and many companies skipped the migratio

RE: [PHP-DEV] [RFC] PHP Attributes

Hi! > From: dmi...@zend.com >> On 04/22/2016 02:46 PM, Thomas Punt wrote: >> Hi Dmitry! >> >> Just a couple of comments on this: >> >> 1. I'd definitely reuse the php-ast extension for parsing the code into an >> AST. It performs a number of transformations on PHP's underlying AST >> that make it

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

On 4/24/2016 2:54 PM, Fleshgrinder wrote: > Another way to illustrate what I mean: > > The feature will be used /to annotate/ (add metadata) and the so > /annotated/ data has additional /attributes/ afterwards. > > Trying building the sentence if the feature is called /attributes/. > > @entity

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

Another way to illustrate what I mean: The feature will be used /to annotate/ (add metadata) and the so /annotated/ data has additional /attributes/ afterwards. Trying building the sentence if the feature is called /attributes/. @entity @invariant final class A { @inject private s

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

I am not arguing against the RFC nor the feature itself, on the contrary, I like it. I just do not like certain aspects and design decisions of it; that is all. Configuration and AOP are the best usecases for annotations and those should be stressed in the RFC. They are not mentioned at all! Anot

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

On 4/24/2016 1:58 PM, Benjamin Eberlei wrote: > The article *you* reference about attributes lists C# attributes as the > *first* example. > > And defines an attribute as: > > "For clarity, attributes should more correctly be considered metadata > . An attr

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

On Sun, Apr 24, 2016 at 1:55 PM, Fleshgrinder wrote: > On 4/24/2016 1:36 PM, Benjamin Eberlei wrote: > > On Sun, Apr 24, 2016 at 10:24 AM, Fleshgrinder > wrote: > > > >> The invariant could also be added as an additional branch to the class > >> instead of a method, since it would not work like

RE: [PHP-DEV] [RFC] PHP Attributes

> -Original Message- > From: Fleshgrinder [mailto:p...@fleshgrinder.com] > Sent: Sunday, April 24, 2016 2:49 PM > To: Zeev Suraski ; Sebastian Bergmann > > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] PHP Attributes > > On 4/24/2016

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

On Sun, Apr 24, 2016 at 1:48 PM, Fleshgrinder wrote: > On 4/24/2016 1:00 PM, Zeev Suraski wrote: > > > > > >> -Original Message- > >> From: Sebastian Bergmann [mailto:sebast...@php.net] > >> Sent: Sunday, April 24, 2016 12:14 PM > >> To:

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

On 4/24/2016 1:36 PM, Benjamin Eberlei wrote: > On Sun, Apr 24, 2016 at 10:24 AM, Fleshgrinder wrote: > >> The invariant could also be added as an additional branch to the class >> instead of a method, since it would not work like a method. >> >> class A {} invariant {} >> >> function f() {}

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

On 4/24/2016 1:00 PM, Zeev Suraski wrote: > > >> -Original Message- >> From: Sebastian Bergmann [mailto:sebast...@php.net] >> Sent: Sunday, April 24, 2016 12:14 PM >> To: internals@lists.php.net >> Subject: Re: [PHP-DEV] [RFC] PHP Attributes >>

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

On Sun, Apr 24, 2016 at 10:24 AM, Fleshgrinder wrote: > The invariant could also be added as an additional branch to the class > instead of a method, since it would not work like a method. > > class A {} invariant {} > > function f() {} require {} ensure {} > > This would also align nicely wi

RE: [PHP-DEV] [RFC] PHP Attributes

> -Original Message- > From: Sebastian Bergmann [mailto:sebast...@php.net] > Sent: Sunday, April 24, 2016 12:14 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] PHP Attributes > > On 04/21/2016 11:13 PM, Dmitry Stogov wrote: > > I would like

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

On Sun, Apr 24, 2016 at 1:09 AM, Thomas Bley wrote: > The <<>> syntax comes with the problem that previous versions cannot > ignore it on parsing. > So poeple write new frameworks for 7.0 which cannot be parsed in 5.x, then > they write new frameworks for 7.1 which cannot be parsed with 7.0 and 5

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

On 04/21/2016 11:13 PM, Dmitry Stogov wrote: > I would like to present an RFC proposing support for native annotation. Dmitry, please use "annotation" as the name for this feature and not "attribute". We already have attributes: it's what we use to store data in objects. And while some people ca

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

The invariant could also be added as an additional branch to the class instead of a method, since it would not work like a method. class A {} invariant {} function f() {} require {} ensure {} This would also align nicely with closures and anonymous classes, which is kind a problematic with a

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

On 24/04/16 08:53, Fleshgrinder wrote: > That is the nature of a feature release, you find many of those in any > PHP feature release. Think of for instance `yield`, directly results in > a parse error in older PHP versions. There are two types of 'BC' problems which need to be catered for. The ea

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

On 4/24/2016 1:48 AM, Benoit Schildknecht wrote: > If I was a popular framework creator, this wouldn't stop me. I would > release two packages : one for 7.0, another one for 7.1. And the 7.0 one > would be the 7.1 one that has been processed through a script to remove > any <<>> syntax, or to trans

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

The <<>> syntax comes with the problem that previous versions cannot ignore it on parsing. So poeple write new frameworks for 7.0 which cannot be parsed in 5.x, then they write new frameworks for 7.1 which cannot be parsed with 7.0 and 5.x and so on. For companies staying on Linux distributions w

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

If I was a popular framework creator, this wouldn't stop me. I would release two packages : one for 7.0, another one for 7.1. And the 7.0 one would be the 7.1 one that has been processed through a script to remove any <<>> syntax, or to transform it (if pre/post attributes instructions were

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

Hi Dimitry, On Fri, Apr 22, 2016 at 6:13 AM, Dmitry Stogov wrote: > I would like to present an RFC proposing support for native annotation. > > The naming, syntax and behavior are mostly influenced by HHVM Hack, but not > exactly the same. > > The most interesting difference is an ability to use

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

On 4/22/2016 4:15 AM, Sara Golemon wrote: > All that said, I love the proposal overall, and I can't wait to > propose builtin annotations like <<__Memoize>>, <<__Mock>>, and > similar. > I'd rather see these two functionalities added as modifiers at the language level instead since they change th

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

+1 for the basic idea, however, I have various remarks. The RFC text is hard to read and contains many grammatical mistakes. How could one help you here? I think that the Hack name attributes is unintelligible and annotations would be much clearer to any audience. Simply because the name is very

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

On 04/22/2016 02:46 PM, Thomas Punt wrote: Hi Dmitry! Hi, I would like to present an RFC proposing support for native annotation. The naming, syntax and behavior are mostly influenced by HHVM Hack, but not exactly the same. The most interesting difference is an ability to use arbitrary P

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

On 22 April 2016 at 11:39, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote: > > > > > > > On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote: > > > > Hi Dmitry, > > > > As a previous suggester of metadata information built-

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

On 4/22/16 10:39 AM, guilhermebla...@gmail.com wrote: On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote: 3- Did you put any thought on inheritance? What I mentioned in comment #1 is even smaller than what you implemented in RFC. Assuming you keep the RFC approach, did you consider support

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

On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote: > > > On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote: > > Hi Dmitry, > > As a previous suggester of metadata information built-in into PHP, and > also one of developers of the most used metadata library written in PHP, I > understand

RE: [PHP-DEV] [RFC] PHP Attributes

Hi Dmitry! > Hi, > > > I would like to present an RFC proposing support for native annotation. > > The naming, syntax and behavior are mostly influenced by HHVM Hack, but not > exactly the same. > > The most interesting difference is an ability to use arbitrary PHP > expressions as attribute val

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

tity"]=> bool(true) } <> - doesn't work now, but I'll implement this and extend RFC on next week. Thanks. Dmitry. From: Dominic Grostate Sent: Friday, April 22, 2016 11:31 To: Dmitry Stogov Cc: PHP internals Subject: Re: [PHP-DEV] [R

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

On 21/04/16 22:13, Dmitry Stogov wrote: > I would like to present an RFC proposing support for native annotation. I thought that the debate had been completed on annotation, and since most of the work can be done in a stand alone extension, the various parties were going to take that route and dev

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

On 22/04/2016 08:17, Dmitry Stogov wrote: On 04/22/2016 05:15 AM, Sara Golemon wrote: On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov wrote: I would like to present an RFC proposing support for native annotation. I'm trying to imagine where the benefit of non-constant expressions comes in.

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

I'm having a crack at it now. Seeing if I can use it to plug a new Annotation driver for Doctrine. Couple of things I've found so far are: <> with empty args doesn't work. <> namespace doesn't work. On the subject of using @, that could denote a class constructor, unless someone already mention

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

On 04/22/2016 05:15 AM, Sara Golemon wrote: On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov wrote: I would like to present an RFC proposing support for native annotation. I'm trying to imagine where the benefit of non-constant expressions comes in. <> Assuming we roll in php-ast at the sam

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

On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote: Hi Dmitry, As a previous suggester of metadata information built-in into PHP, and also one of developers of the most used metadata library written in PHP, I understand this feature implementation requires several design decisions and

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

On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov wrote: > I would like to present an RFC proposing support for native annotation. > I'm trying to imagine where the benefit of non-constant expressions comes in. <> Assuming we roll in php-ast at the same time (which is a big addition, IMO, and deser

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

Hi Dmitry, As a previous suggester of metadata information built-in into PHP, and also one of developers of the most used metadata library written in PHP, I understand this feature implementation requires several design decisions and also a good understanding of specific situations users may requi

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

On 04/22/2016 02:16 AM, Dominic Grostate wrote: This is amazing. It would actually allow us to implement our automated assertions ourselves, as opposed to requiring it within the language. this was the idea - to give a good tool instead of implementing every possible use-case in the lang

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

On 04/22/2016 02:09 AM, Colin O'Dell wrote: > A more robust alternative would be something along the same lines that > Doctrine uses: Make annotations actual classes. Just spitballing here - what if both approaches were supported, but class-based annotations were prefixed with a special chara

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

On 04/22/2016 02:02 AM, Ryan Pallas wrote: On Thu, Apr 21, 2016 at 4:51 PM, Dmitry Stogov > wrote: About expressions, isn't there an ambigoutiy? <> is a "plain" name, value based attribute. But it could also be an ast\node of a function call

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

This is amazing. It would actually allow us to implement our automated assertions ourselves, as opposed to requiring it within the language. Could it also support references? <> function foo($a) { } On 21 Apr 2016 10:13 p.m., "Dmitry Stogov" wrote: > Hi, > > > I would like to present an RFC p

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

> > $r = new ReflectionClass('ORM\Entity'); > var_dump($r->getAttributes()); > Oops, that should've been: $r = new ReflectionClass('Foo'); var_dump($r->getAttributes()); Colin

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

> A more robust alternative would be something along the same lines that > Doctrine uses: Make annotations actual classes. Just spitballing here - what if both approaches were supported, but class-based annotations were prefixed with a special character (perhaps "@") to differentiate them? For ex

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

On Thu, Apr 21, 2016 at 4:51 PM, Dmitry Stogov wrote: > > >> About expressions, isn't there an ambigoutiy? <> is a "plain" >> name, value based attribute. But it could also be an ast\node of a function >> call to "test(1)" >> > even in AST scalars are scalars. > so <> would return: ast\node "+" wi

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

On 04/22/2016 01:03 AM, Benjamin Eberlei wrote: On Thu, Apr 21, 2016 at 11:13 PM, Dmitry Stogov > wrote: Hi, I would like to present an RFC proposing support for native annotation. The naming, syntax and behavior are mostly influenced by HHVM Ha

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

On 04/22/2016 12:52 AM, Larry Garfield wrote: On 4/21/16 4:13 PM, Dmitry Stogov wrote: Hi, I would like to present an RFC proposing support for native annotation. The naming, syntax and behavior are mostly influenced by HHVM Hack, but not exactly the same. The most interesting difference

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

On Thu, Apr 21, 2016 at 11:52 PM, Larry Garfield wrote: > On 4/21/16 4:13 PM, Dmitry Stogov wrote: > >> Hi, >> >> >> I would like to present an RFC proposing support for native annotation. >> >> The naming, syntax and behavior are mostly influenced by HHVM Hack, but >> not exactly the same. >> >>

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

On 4/21/16 4:13 PM, Dmitry Stogov wrote: Hi, I would like to present an RFC proposing support for native annotation. The naming, syntax and behavior are mostly influenced by HHVM Hack, but not exactly the same. The most interesting difference is an ability to use arbitrary PHP expressions a