Re: [PHP-DEV] [RFC] Reflection annotations reader

On 9 January 2013 01:08, Rasmus Schultz wrote: > I've started working on a new proposal, but I'm getting hung up on the > syntax - if we can't use angle brackets anymore, what can we use? Virtually > every symbol on a standard US keyword is an operator of some sort, does > that mean those are all

Re: [PHP-DEV] [RFC] Reflection annotations reader

In my opinion (for however little it matters), code is code, and comments are comments. They should not mingle. Annotations, if implemented, should have their own syntax that makes them code, not an abstraction of a comment. I already dislike the fact that getDocComment is there - in my opinion a

Re: [PHP-DEV] [RFC] Reflection annotations reader

On Wed, Jan 9, 2013 at 10:29 AM, Leigh wrote: > In my opinion (for however little it matters), code is code, and comments > are comments. They should not mingle. > > Annotations, if implemented, should have their own syntax that makes them > code, not an abstraction of a comment. > > I already di

RE: [PHP-DEV] [RFC] Reflection annotations reader

+1 I totally agree with Leigh. In my opinion comments should not be abused for any logic. This is the reason I've never used the annotations for Doctrine, although it is a nice feature. -Original Message- From: Leigh [mailto:lei...@gmail.com] Sent: Wednesday, January 09, 2013 9:30 AM T

[PHP-DEV] - True Annotations

Just starting a new thread here to discuss true annotations vs a DocBlock Parser: RFC Referenced: https://wiki.php.net/rfc/annotations On 1/9/2013 2:09 AM, Peter Cowburn wrote: On 9 January 2013 01:08, Rasmus Schultz wrote: I've started working on a new proposal, but I'm getting hung up on

Re: [PHP-DEV] - True Annotations

Very good RFC ! "Annotation" might be better than "ReflectionAnnotation" ? Possible usage of "annotation" as keyword instead of an abstract class: - abstract class seems more logicial Nested Annotation declaration: )> or : - )> for consistency Le 09/01/2013 11:53, Clint Priest a écrit : Just

Re: [PHP-DEV] - True Annotations

On Wed, 9 Jan 2013, Clint Priest wrote: > Just starting a new thread here to discuss true annotations vs a DocBlock > Parser: > > RFC Referenced: > > https://wiki.php.net/rfc/annotations > > > On 1/9/2013 2:09 AM, Peter Cowburn wrote: > > On 9 January 2013 01:08, Rasmus Schultz wrote: > > > I

Re: [PHP-DEV] [RFC] Reflection annotations reader

On Mon, 7 Jan 2013, Yahav Gindi Bar wrote: > I don't think that we should dictate the syntax for each application. > Each application will get the doc-comment annotation and will be able > to apply on it its own syntax and fancy stuff... And this is the exact reason why I think it makes no sens

Re: [PHP-DEV] - True Annotations

Hi, I agree here, I think the above, if possible would be best. In my mind annotations should proabably be limited in scope to class declarations and thus only before a class keyword, before a property or method declaration. In none of those scopes would [ ] be a parsing issue I believe... Th

Re: [PHP-DEV] - True Annotations

Hi internals, I would like to give you my thoughts about annotations. An annotation *must not change* the code *behavior* but add a useful *information* for the users or *tools*. The syntax used most of the time is very restrictive (such as Foo('Bar'), DateType('datetime'), MinLength(42) etc

Re: [PHP-DEV] - True Annotations

On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps wrote: > Hi, > > > I agree here, I think the above, if possible would be best. In my >> mind annotations should proabably be limited in scope to class >> declarations and thus only before a class keyword, before a property >> or method declaration.

Re: [PHP-DEV] - True Annotations

Am 09.01.2013 13:03, schrieb Yahav Gindi Bar: On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps wrote: Hi, I agree here, I think the above, if possible would be best. In my mind annotations should proabably be limited in scope to class declarations and thus only before a class keyword, befor

Re: [PHP-DEV] [RFC] Reflection annotations reader

On Tue, 8 Jan 2013, Pierrick Charron wrote: > On 8 January 2013 03:55, Stas Malyshev wrote: > > > On the contrary, plenty of implementations means there's a need in > > this functionality, and it might be a good idea to have one standard > > implementation if it can cover like 80% of use cases.

[PHP-DEV] Docblocks vs Annotations (Was: Re: [PHP-DEV] [RFC] Reflection annotations reader)

On Tue, 8 Jan 2013, Mike van Riel wrote: > As far as I am concerned I'd separate this topic into a DocBlock > parser (that might take into account the current state of affairs with > DocBlock Annotations) and actual Annotation support. Yup - two different things. Something akin an extension tha

Re: [PHP-DEV] [RFC] Reflection annotations reader

Taken from the Doctrine documentation: wrote: > On Tue, 8 Jan 2013, Pierrick Charron wrote: > >> On 8 January 2013 03:55, Stas Malyshev wrote: >> >> > On the contrary, plenty of implementations means there's a need in >> > this functionality, and it might be a good idea to have one standard >> >

Re: [PHP-DEV] - True Annotations

On Wed, Jan 9, 2013 at 2:09 PM, Christian Kaps wrote: > Am 09.01.2013 13:03, schrieb Yahav Gindi Bar: > >> On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps > >**wrote: >> >> Hi, >>> >>> >>> I agree here, I think the above, if possible would be best. In my >>> mind annotations should proababl

Re: [PHP-DEV] [RFC] Reflection annotations reader

Well, Derick, > And really, nobody can convince me that we would need stuff like: > > @MyApp\Acl({ > "allow"=@MyApp\Acl\Allow({"john"="read", "joe"="write"}), > "deny"=@OtherApp\Acl\Deny(default="*", log=true) > }) > > cheers, > Derick > that actually worked quite well in an old ZF1 MVC

Re: [PHP-DEV] [RFC] Reflection annotations reader

On Tue, 8 Jan 2013, Rafael Dohms wrote: > On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev wrote: > > > > Everyone I talked to who implemented annotations in docblocks did it > > > as hack because there is no native support. This is not something that > > > belongs to docblocks. It would be nice if

Re: [PHP-DEV] [RFC] Reflection annotations reader

Please, no top posting!!! On Wed, 9 Jan 2013, Vladislav Veselinov wrote: > Taken from the Doctrine documentation: > > class User > { > //... > /** > * @ManyToMany(targetEntity="Group") > * @JoinTable(name="User_Group", > * joinColumns={@JoinColumn(name="User_id", >

Re: [PHP-DEV] - True Annotations

Annotations can be nested so in this case [Foo([BAR])] there is a big ambiguity and we can not determine if [BAR] is an array with the BAR constant in it or an annotation. Pierrick On 9 January 2013 05:53, Clint Priest wrote: > In none of those scopes would [ ] be a parsing issue I believe... -

Re: [PHP-DEV] - True Annotations

Regarding syntax... Would this work? <|foo|> <|bar( <|baz|> )|> best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] - True Annotations

No please, two symbols for each side looks ugly. BTW There's number sign (#) which is, as far as I remember, not used in PHP at all. Could be something like: #JoinColumn(name="...", type="...", ...) #Foo(Bar()) Or #Foo(#Bar()) (should we put a "annotation-sign" in front of a nested annotatio

Re: [PHP-DEV] - "attributes" rather than "annotations"

We should probably be referring to this type of syntax as attributes rather than annotations since annotations are currently defined in docblock comments and are recognized by certain software and utilities. Whereas annotations have no effect on compilation or at runtime, attributes do have th

Re: [PHP-DEV] - True Annotations

# is an alternative syntax for comments On 9 January 2013 08:27, Nikita Nefedov wrote: > #Foo(#Bar()) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] - True Annotations

The # would be parsed as a comment Kind Regards Pierre du Plessis *Cell*: 072 775 3477 *Fax*: 086 650 4991 *Email*: i...@customscripts.co.za *www*: http://www.customscripts.co.za On Wed, Jan 9, 2013 at 3:27 PM, Nikita Nefedov wrote: > No please, two symbols for each side looks ugly. > BTW T

Re: [PHP-DEV] [RFC] Reflection annotations reader

On Wed, Jan 9, 2013 at 1:42 PM, Derick Rethans wrote: > Please, no top posting!!! > > On Wed, 9 Jan 2013, Vladislav Veselinov wrote: > > > Taken from the Doctrine documentation: > > > > > class User > > { > > //... > > /** > > * @ManyToMany(targetEntity="Group") > > * @JoinTabl

Re: [PHP-DEV] - True Annotations

I think this RFC syntax is outdated. We can remove the whole new syntax and just make everything between <> php code that returns the last statement because of the array short syntax this ends up to be stuff like: <['foo' => bar']> <['foo' => foo()]> <['foo' => new Foo('bar')]> This would greatly

Re: [PHP-DEV] - True Annotations

> https://wiki.php.net/rfc/annotations Perhaps I am blind, but I do not see where in the RFC is defends its choice to use `<>`. Every other language I know of uses `@`, and I do not know of technical reasons why we couldn't use the same symbol. Annotations wouldn't be able to contain expressions s

Re: [PHP-DEV] [RFC] Reflection annotations reader

On Wed, Jan 9, 2013 at 3:48 PM, Benjamin Eberlei wrote: > On Wed, Jan 9, 2013 at 1:42 PM, Derick Rethans wrote: > >> Please, no top posting!!! >> >> On Wed, 9 Jan 2013, Vladislav Veselinov wrote: >> >> > Taken from the Doctrine documentation: >> > >> > > > class User >> > { >> > //... >> >

Re: [PHP-DEV] - True Annotations

Every other language used :: or . for namespaces. The problem with @ is its definition as error suppression operator, and Guilherme and Pierrick didn't come up with a solution to stay BC using the @. Additionally some other languages use [] (which also doesnt work in PHP). On Wed, Jan 9, 2013 at

Re: [PHP-DEV] - True Annotations

Levi, On Wed, Jan 9, 2013 at 10:15 AM, Levi Morrison wrote: > > https://wiki.php.net/rfc/annotations > > Perhaps I am blind, but I do not see where in the RFC is defends its > choice to use `<>`. Every other language I know of uses `@`, and I do > not know of technical reasons why we couldn't use

Re: [PHP-DEV] - True Annotations

> be anything that could generate a suppressible error. Not true: @ORM\Column() class Test() { } What if there's a function in the ORM namespace called Column. Is this a supressed error of a function call and we've missed the ";" or is it an annotation? -- PHP Internals - PHP Runtime Developm

Re: [PHP-DEV] - True Annotations

On Wed, Jan 9, 2013 at 8:20 AM, Anthony Ferrara wrote: > Levi, > > On Wed, Jan 9, 2013 at 10:15 AM, Levi Morrison > wrote: >> >> > https://wiki.php.net/rfc/annotations >> >> Perhaps I am blind, but I do not see where in the RFC is defends its >> choice to use `<>`. Every other language I know of

Re: [PHP-DEV] - True Annotations

Levi Maybe I'm a complete fool, but since annotations aren't executed (they > are declarative only), this should cause no problems. > You're not a fool. And the point is not that they are executed, but because they are nearly syntactically identical to executable code. So parser and readability w

Re: [PHP-DEV] - True Annotations

> they are nearly syntactically identical to executable code. "nearly" is the keyword there. They lack the ending semi-colon. Sure, this might mean PHP has to actually use an abstract syntax tree, but that's long overdue in my opinion. I know others disagree. This is only tangentially related, so

[PHP-DEV] [VOTE] zend_parse_parameters() improvements

I've opened voting for the zend_parse_parameters() improvements RFC. You can now go to https://wiki.php.net/rfc/zpp_improv#voting Regards -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] - True Annotations

On 1/9/13 9:31 AM, Levi Morrison wrote: they are nearly syntactically identical to executable code. "nearly" is the keyword there. They lack the ending semi-colon. Sure, this might mean PHP has to actually use an abstract syntax tree, but that's long overdue in my opinion. I know others disagre

Re: [PHP-DEV] - True Annotations

> Let's not subsidize the headache drug manufacturers with PHP syntax > decisions. :-) Too late. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] - True Annotations

Before we all bikeshed on the syntax, shouldn't we be figuring out the feature-set first? Over in PHP-FIG, we've found it useful to audit the existing market to see what's in use. That doesn't dictate decisions we make, but it can be instructional. Eg, if we find that most annotation-using p

Re: [PHP-DEV] - True Annotations

On Wed, Jan 9, 2013 at 5:20 PM, Larry Garfield wrote: > On 1/9/13 9:31 AM, Levi Morrison wrote: > >> they are nearly syntactically identical to executable code. >>> >> >> "nearly" is the keyword there. They lack the ending semi-colon. Sure, >> this might mean PHP has to actually use an abstract sy

Re: [PHP-DEV] [RFC] Reflection annotations reader

On 01/09/2013 04:16 AM, Derick Rethans wrote: > On Tue, 8 Jan 2013, Rafael Dohms wrote: >> 1. The syntax is crap: this is solvable, let's find the right syntax > > Any extra syntax makes the PHP parser more complicated (and arguably > slower). I don't want to have it slower/more complex for some

Re: [PHP-DEV] - True Annotations

Hi! > Just starting a new thread here to discuss true annotations vs a > DocBlock Parser: > > RFC Referenced: > > https://wiki.php.net/rfc/annotations Didn't look into it in detail but one note - can we please come up with something that doesn't look like broken HTML? -- Stanislav Malyshev,

Re: [PHP-DEV] - True Annotations

Why don't we pick a commonly used annotation symbol like * then? It currently can't start an expression so there's not an ambiguity (that I can think of). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] - "attributes" rather than "annotations"

Hi! > > class a { > [php:Param($s) = StringLength(4, ErrorMessage='Parameter $s length > cannnot exceed 4.', ErrorLevel=E_USER_ERROR)] > public function foo($s) { ... ] > } What this is supposed to do? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408

Re: [PHP-DEV] [RFC] Reflection annotations reader

Hi, I agree with you on this point, we should not introduce any new feature if there is no way to deal with largely used extensions like apc, xdebug or maybe others. The provided implementation is not supposed to be final (syntax or internal implementation) and I'm sure there are many improvements

Re: [PHP-DEV] [RFC] Reflection annotations reader

Hi! > @MyApp\Acl({ > "allow"=@MyApp\Acl\Allow({"john"="read", "joe"="write"}), > "deny"=@OtherApp\Acl\Deny(default="*", log=true) > }) I seriously hope it never comes to this in PHP. We're supposed to be simple language for doing cool stuff on the web, not a serialization format for ORM m

[PHP-DEV] Was Reflection annotations reader - Pull APC in Core Already

Rasmus This is my worry as well. Especially when it comes to opcode cache > support. Most of the patches I see these days completely ignore the > opcode cache side of things which needs to change. For any large > language-level change, any implementation that doesn't also include an > APC diff, o

[PHP-DEV] Re: Was Reflection annotations reader - Pull APC in Core Already

On Wed, 9 Jan 2013, Anthony Ferrara wrote: > Rasmus wrote: > > > This is my worry as well. Especially when it comes to opcode cache > > support. Most of the patches I see these days completely ignore the > > opcode cache side of things which needs to change. For any large > > language-level ch

[PHP-DEV] Re: Was Reflection annotations reader - Pull APC in Core Already

On 01/09/2013 09:03 AM, Anthony Ferrara wrote: > Rasmus > > > This is my worry as well. Especially when it comes to opcode cache > support. Most of the patches I see these days completely ignore the > opcode cache side of things which needs to change. For any large > language-leve

Re: [PHP-DEV] Re: Was Reflection annotations reader - Pull APC in Core Already

On Wed, Jan 9, 2013 at 6:06 PM, Derick Rethans wrote: > On Wed, 9 Jan 2013, Anthony Ferrara wrote: > > > Rasmus wrote: > > > > > This is my worry as well. Especially when it comes to opcode cache > > > support. Most of the patches I see these days completely ignore the > > > opcode cache side of

[PHP-DEV] Re: Was Reflection annotations reader - Pull APC in Core Already

Hi! > While I do see your point, to me it's less of an issue that it breaks > APC, and more of an issue that APC's functionality is not in core. You are confusing specific extension with functionality. The problem is not that specific extension (APC) is not in core, but that the proposal makes fu

Re: [PHP-DEV] Re: Was Reflection annotations reader - Pull APC in Core Already

Hi! > It was a plan in the past, I think we should just do it - now. If you mean moving the directory from pecl to ext/ - that's fine as long as maintainers commit to keeping it in shape (last time, I remember, 5.4 support was lagging). If you mean more tight integration - see my previous email w

[PHP-DEV] Was Reflection annotations reader - We Need A Vision

Stas, On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev wrote: > I seriously hope it never comes to this in PHP Would you shut up with this rhetoric already? All it does is show that you're completely and utterly out of touch with the reality of modern development. Frankly, I'm getting sick and t

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

On 01/09/2013 09:45 AM, Anthony Ferrara wrote: > PHP NEEDS a vision. It needs something to guide development. Not everyone > will agree with it. And that's the point. It levels the playing field for > contributions and discussions. Rather than every developer playing for > themselves and saying "I

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

On 1/9/13 12:09 PM, Rasmus Lerdorf wrote: On 01/09/2013 09:45 AM, Anthony Ferrara wrote: PHP NEEDS a vision. It needs something to guide development. Not everyone will agree with it. And that's the point. It levels the playing field for contributions and discussions. Rather than every developer

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

2013/1/9 Anthony Ferrara > Stas, > > Would you shut up with this rhetoric already? All it does is show that > you're completely and utterly out of touch with the reality of modern > development. > > Frankly, I'm getting sick and tired of seeing these recurring themes of > "PHP is not java" and "I

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

Amaury, Would you shut up with this rhetoric already? All it does is show that >> you're completely and utterly out of touch with the reality of modern >> development. >> >> Frankly, I'm getting sick and tired of seeing these recurring themes of >> "PHP is not java" and "I never want this". If you

[PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

Hi! > Stas, > > On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev > wrote: > > I seriously hope it never comes to this in PHP > > > Would you shut up with this rhetoric already? All it does is show that I admire your politeness and ability to discuss thing wit

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

On Wed, Jan 9, 2013 at 12:45 PM, Anthony Ferrara wrote: > Stas, > > On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev wrote: > >> I seriously hope it never comes to this in PHP > > > Would you shut up with this rhetoric already? All it does is show that > you're completely and utterly out of touch wi

Re: [PHP-DEV] Re: Was Reflection annotations reader - Pull APC in Core Already

On Wed, 9 Jan 2013, Stas Malyshev wrote: > > It was a plan in the past, I think we should just do it - now. > > If you mean moving the directory from pecl to ext/ - that's fine as > long as maintainers commit to keeping it in shape (last time, I > remember, 5.4 support was lagging). If you mean

[PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

Stas, It is a recurring theme because it's true. You are right that every > language needs a vision, and PHP's vision is being simple and practical > and focused on the web. PHP is what people use to get their first site > off the ground. PHP is what a web designer learns when he/she wants to > g

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

On 01/09/2013 11:48 AM, Anthony Ferrara wrote: > Rasmus: "A general purpose scripting language with a focus on web > development" > You: "being simple and practical and focused on the web" > > While they both have "web" in them, they provide very different goals and > metrics with which to gauge c

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

Stas, perhaps you haven't noticed, but you are regularly derailing discussions. I know that there are at least a few other people reading the mailing list who tire of your behavior. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

Just a thought here, but perhaps what PHP needs now is a working group that works together to do some basic management of PHP as a language, take into account what the users are wanting, talking about, requesting and setting a vision and direction and make plans for what will and won't and when

Re: [PHP-DEV] [RFC] Reflection annotations reader

Pierrick, before update v3 of patch, let's first clarify things that need to be discussed. Rasmus, you have no idea how happy you made me for a gentle comment pointing something we should think before propose a patch instead of on (sorry for the wording) bitching about the idea. There're tons of e

Re: [PHP-DEV] - "attributes" rather than "annotations"

I was just looking into C# attributes at the time since I had used them in the past. It was a loose translation to something for php from the example on this page: http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.stringlengthattribute.aspx In essence the example w

Re: [PHP-DEV] [RFC] Reflection annotations reader

This version of annotations (attributes?) is much more interesting than the most recent version, but I could see this syntax as being a problem if it were allowed to apply to plain functions because then the parser would have difficulty distinguishing from an array. I suppose the same could be

Re: [PHP-DEV] [RFC] Reflection annotations reader

Clint, If you switch from [] to <> everything works like a charm. =) Everything was working smoothly on version 2. Version 3 was an attempt to simplify the patch, but removing tons of things that would pop in a few time if patch was accepted. Cheers, On Wed, Jan 9, 2013 at 3:24 PM, Clint Priest

Re: [PHP-DEV] Docblocks vs Annotations (Was: Re: [PHP-DEV] [RFC] Reflection annotations reader)

On 09.01.2013 13:12, Derick Rethans wrote: There is a tokenizer for this already that Greg wrote ages ago in pecl: http://pecl.php.net/package/docblock - why can't that be extended to parse your style of annotations in docblocks? To be honest; I haven't had the time yet to learn and apply exte

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

On 1/9/13 1:55 PM, Clint Priest wrote: Just a thought here, but perhaps what PHP needs now is a working group that works together to do some basic management of PHP as a language, take into account what the users are wanting, talking about, requesting and setting a vision and direction and make p

Re: [PHP-DEV] strtr vs. str_replace runtime

On Thu, 03 Jan 2013 11:40:31 +0100, Gustavo Lopes wrote: The algorithm behaves very poorly in this case because at each position of the text, all the substrings starting there and with size between m and n (where m is the size of the smallest pattern and n is the largest) are checked, ev

Re: [PHP-DEV] [RFC] Reflection annotations reader

On 2013-01-09, Rasmus Lerdorf wrote: > On 01/09/2013 04:16 AM, Derick Rethans wrote: >> On Tue, 8 Jan 2013, Rafael Dohms wrote: > >>> 1. The syntax is crap: this is solvable, let's find the right syntax >> >> Any extra syntax makes the PHP parser more complicated (and arguably >> slower). I don'

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

On 10 January 2013 03:00, Anthony Ferrara wrote: > Well, the point is that there are two ways of voicing your dislike. You can > say "I never want this" or other rhetoric, which helps nobody else but to > understand that you don't want it. Or you can be a little bit more civil > and reply detailin

Re: [PHP-DEV] [RFC] Reflection annotations reader

I'm going to address these question in the proposal I'm working on - once it's all in writing, I will post for debate. On Wed, Jan 9, 2013 at 2:57 PM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > - Should we support nested annotations? > > - How [Foo()] will be different from n

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

Annotations are already a part of PHP. They are widely used in one of the most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine. Both of which are serious drivers of the PHP community. It's even potentially spreading to Zend Framework: http://zend-framework-community.634137.n4.nabb

Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

On Wed, Jan 9, 2013 at 2:48 PM, Anthony Ferrara wrote: > > > Am I guilty of being abusive? Absolutely. But I hope the abusiveness that I > portray at least tries to be constructive (if it's not always, I'm sorry). > >From the Merriam-Webster dictionary: a·bu·sive /əˈbyo͞osiv/ (1) characterized

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

On Thu, Jan 10, 2013 at 4:05 AM, Tyler Sommer wrote: > Annotations are already a part of PHP. They are widely used in one of the > most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine. > Both of which are serious drivers of the PHP community. It's > even potentially spreading to

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

On 10 January 2013 10:05, Tyler Sommer wrote: > Annotations are already a part of PHP. They are widely used in one of the > most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine. To explain what I meant by "PHP", since I think we're arguing semantics there: I mean php-src specifi

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

Great points, Adam. I disagree with this one feature being excluded but I do agree that just because something is in the userland doesn't necessarily mean it should be in the core-- making my point rather moot. Cheers. On Wed, Jan 9, 2013 at 6:28 PM, Adam Harvey wrote: > On 10 January 2013 10:

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about acceptance of new features. You all claim that PHP is simple, that features include should be widely used and only important functions, classes that have regular and extensive usage would be in. I wonder how Annotations is dif

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

> Also talking about widely used support, I wonder about how > SplDoubleLinkedList, SplInt, SplMaxHeap and all these classes that have > very specific usages, just like also data structure readers like > json_decode, parse_ini_file are part of the core while others also used as > much as these ones

[PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision

Hi! > You just proved my point with your reply. PHP doesn't have a vision. The > two people in this thread who have provided what they thought were > visions don't agree. And that's a problem. If you mean that there would be some "vision" document that prevents disagreement and decides arguments

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

Hi! > I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about > acceptance of new features. I can answer only for myself of course, but I don't have any single "criteria". I look at the feature, how it can be used, how it can be abused, how it would be seen by experienced PHP deve

[PHP-DEV] Recommended ignore list for GIT/SVN?

Is there any official/doctrinal list of file types for a GIT/SVN ignore list when working on a PECL extension? I've been snooping around and found the following (from http://stackoverflow.com/questions/85353/best-general-svn-ignore-pattern) but was wondering if there was any ignore list that i

Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision

guilhermebla...@gmail.com wrote: I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about acceptance of new features. You all claim that PHP is simple, that features include should be widely used and only important functions, classes that have regular and extensive usage would be i

Re: [PHP-DEV] - "attributes" rather than "annotations"

Hi! > In essence the example would be something along the lines of "$s must be > a string with length exactly 4 and if not, trigger_error() with the > given error message and error level. OK, I see what you mean, but it is still unclear what such construct does. At least conceptually, I do not