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

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

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

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

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

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

ust because HHVM is closer to PHP than C#. >> >> >> >> From: Dominic Grostate <codekest...@googlemail.com> >> Sent: Tuesday, April 26, 2016 19:43 >> To: Dmitry Stogov >> Cc: rowan.coll...@gmail.com; PHP internals; Stanislav Malyshev >> Subject: Re: [PHP-DEV]

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

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

; > 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("My Function")] > function my_function() > {}

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

Just because HHVM is closer to PHP than C#. From: Dominic Grostate <codekest...@googlemail.com> 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

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

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

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

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

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

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

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

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

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

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

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

Stogov Cc: Dominic Grostate; PHP 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 2

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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!

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

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

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 <z...@zend.com>; Sebastian Bergmann > <sebast...@php.net> > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] PHP

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

, 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 to present an RFC proposing support for native annotation. > >> > &

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ot;Entity"]=> bool(true) } <<ORM\Entity>> - doesn't work now, but I'll implement this and extend RFC on next week. Thanks. Dmitry. From: Dominic Grostate <codekest...@googlemail.com> Sent: Friday, April 22, 2016 11:31 To: Dmitry Stogo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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