# Was Reflection annotations reader - We Need A Vision - Thread: https://externals.io/message/64770 - Original archive: https://news-web.php.net/php.internals/64770 - Started by Anthony Ferrara on 2013-01-09T17:45:47+00:00 - Messages: 45 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/64770.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #64770 — Anthony Ferrara — 2013-01-09T17:45:47+00:00 URL: https://externals.io/message/64770#64770 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 tired of seeing these recurring themes of "PHP is not java" and "I never want this". If you never want this, then don't contribute to the discussions at all. If you have solid feedback to provide, then provide it. But saying "We're supposed to be simple language for doing cool stuff on the web" shows you have no idea what people have been doing (or don't want to acknowledge) with the language for the past 5 years. And that brings us to the root of the problem. Discussion like this is due to the fact that there's no clear "official" vision for PHP. Each participant brings their own concept and vision, and treats it like it's everyone else's vision as well (which is the exact reason for your reply). The need for voting is a byproduct of this lack of vision, not a requirement in its own right. For all the problems that a Benevolent Dictator brings to a project, this is not one of them. This is a case where a dictator that sets the vision in clear and unambiguous terms would actually improve the process quite significantly. Instead of worrying about voting or everyone doing what they want, there's a benchmark to measure proposals against. For example, imagine these different visions for PHP (which I know for a fact are shared on this list): 1. "PHP Should Strive To Be A Full Featured Object Oriented Language". In this context frame, things like annotations, mixins, generators, etc become the focus. As would moving the error handler to exceptions. And a host of other changes (boxing primitive types when treated like an object, etc). Adding functions like array_get_whatever would be frowned upon... 2. "PHP Should Remain A Procedural Language WIth Some OO Features" In this context frame, a lot of the stuff I said above goes away. And adding new array functions would be the norm. And it's plain to tell that exceptions shouldn't be implemented for errors. 3. "PHP Should Be Implementation Neutral, and Support All Paradigms Equally". This is as close to the current implementation as we currently are. We support procedural, OOP and functional constructs. But how deep does it go? Where's the line. 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 hope this never happens", it puts it in the context of "I don't believe this fits our vision". Note the difference in tone between them. It's an ongoing joke about how abusive and unproductive the internals list is. I for one am sick of it. And rather than keeping ignoring it (or walking away), I'd rather see it fixed. Anthony --- ## #64771 — Rasmus Lerdorf — 2013-01-09T18:09:09+00:00 URL: https://externals.io/message/64770#64771 · In reply to: #64770 > 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 hope this never happens", it puts it in the > context of "I don't believe this fits our vision". Note the difference in > tone between them. The vision has been the same for years. A general purpose scripting language with a focus on web development. You are simply saying you want the vision to be more specific than that because everyone has a different view of what web development means. But even if we narrow the vision, it will still be open to a lot interpretation. We try to strike a balance between the different and changing views of web development the same way we strike a balance between appealing to weekend warriors and top-100 trafficed sites. No vision statement is going to answer the question of whether annotations should be in docblocks or in the core language. That's simply not what vision statements do. -Rasmus --- ## #64772 — Larry Garfield — 2013-01-09T18:21:13+00:00 URL: https://externals.io/message/64770#64772 · In reply to: #64771 > > > > […] > > The vision has been the same for years. A general purpose scripting > language with a focus on web development. You are simply saying you want > the vision to be more specific than that because everyone has a > different view of what web development means. But even if we narrow the > vision, it will still be open to a lot interpretation. We try to strike > a balance between the different and changing views of web development > the same way we strike a balance between appealing to weekend warriors > and top-100 trafficed sites. No vision statement is going to answer the > question of whether annotations should be in docblocks or in the core > language. That's simply not what vision statements do. > > -Rasmus Sure. A vision statement won't say "annotations FTW" or "Objects FTL". But it provides a soft metric and rough target toward which to keep moving, and we can all subjectively measure proposals against that metric, rather than subjectively against our own personal metrics. As a former member of the Board of Directors for the Drupal Association, I feel having a formal visioning process is one of the best things we ever did. +1 to Anthony on needing an actual publicly-documented vision for the PHP project. Even if it doesn't have a BDFL, having some clear standard against which we measure the essence of proposals would be beneficial. --Larry Garfield --- ## #64773 — Amaury Bouchard — 2013-01-09T18:35:01+00:00 URL: https://externals.io/message/64770#64773 · In reply to: #64770 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 never want this". If you never want this, then > don't contribute to the discussions at all. > What's the point? If only those who agree can talk, I'm not sure about the result... If Stas doesn't like the proposed syntax, how can he express his dislike in a sufficiently positive manner? (it's a honest candid question; I'm asking it even after receiving nice and harsh responses to my patch proposal last summer) > PHP NEEDS a vision. Rasmus' answer was about balance. I guess it's hard to strongly define what a language should be; there is no drawable line. Each step is questionable in some way, This balance is the strength of PHP, the root of its flexibility. But I totally understand your frustration. --- ## #64774 — Anthony Ferrara — 2013-01-09T19:00:47+00:00 URL: https://externals.io/message/64770#64774 · In reply to: #64773 Amaury, Would you shut up with this rhetoric already? All it does is show that > > […] > > What's the point? If only those who agree can talk, I'm not sure about the > result... > > If Stas doesn't like the proposed syntax, how can he express his dislike > in a sufficiently positive manner? (it's a honest candid question; I'm > asking it even after receiving nice and harsh responses to my patch > proposal last summer) > 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 detailing your concerns, and say "Based on that, I don't like it". There's a HUGE difference between the two. One puts a foot down on the ground. The other shares concerns and lets people learn from why. To be fair, Stas did do a good job in those threads voicing his concerns. But IMHO the "I never want this" and similar rhetoric has no place on a mailing list for a language in an Open Source project... > > > > […] > > > Rasmus' answer was about balance. I guess it's hard to strongly define > what a language should be; there is no drawable line. Each step is > questionable in some way, This balance is the strength of PHP, the root of > its flexibility. > But I totally understand your frustration. > Well, I'm not saying we should "strongly define" the language. I'm just saying a vision statement that's a little more specific than "web language" would frame the discussions in a context that could make them significantly more productive... But it shouldn't be so rigid that there's a drawable line. But the line should be implied enough that the discussion around a feature leads to the precise line. As it currently stands the discussion is more akin to determining if a line exists, yet alone where it is... Anthony --- ## #64775 — Stas Malyshev — 2013-01-09T19:01:57+00:00 URL: https://externals.io/message/64770#64775 · In reply to: #64770 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 without resorting to insults and personal attacks. No, I will definitely not shut up. > you're completely and utterly out of touch with the reality of modern > development. Really. I was going to write a refutation to that but on the second thought screw it. You are wrong, and you know it, and I'm not going to waste time to dignify that with any more response. > Frankly, I'm getting sick and tired of seeing these recurring themes of > "PHP is not java" and "I never want this". If you never want this, then > don't contribute to the discussions at all. 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 go into programming. PHP is what a random Joe uses when he needs to whip up a page and he's in "do it yourself" mind. PHP is what you expect everybody to be able to handle, and everything to be able to run. It is not to serve everybody, every use case and every possible need. Yes, we try to extend the boundaries and do clever things - but sometimes we have to make a choice. You can not be everything to everybody. And if the choice between some complicated use-case that will be used by maybe 1% of the users and even then will be buried in the guts of some huge library and simplicity and accessibility of the language - I choose the latter every time. Library writers are smart, they can work around it and nobody but them will see it anyway. But turning the language into Java wannabe would affect all the users. And most of them don't need that, in my opinion. That doesn't mean we should not improve and go forward. We should. But we should do it consistent with yes - the vision of the language being accessible and not overly complex. If you want rigid OO-pattern-driven language - you have Java. If you want full mathematics power with full mathematics complexity - you got Scala and Haskell and so on. There's nothing wrong with them. They are just not PHP and PHP is not them. They have their playground and we have ours. Having vision does mean sometimes having to say "PHP is not X" and reject stuff because of that. > If you have solid feedback to provide, then provide it. But saying > "We're supposed to be simple language for doing cool stuff on the web" > shows you have no idea what people have been doing (or don't want > to acknowledge) with the language for the past 5 years. I have feedback to provide and I provide it all the time. But if by "solid" you mean agreeing with you, you're not getting that. > And that brings us to the root of the problem. Discussion like this is > due to the fact that there's no clear "official" vision for PHP. Each > participant brings their own concept and vision, and treats it like it's > everyone else's vision as well (which is the exact reason for your > reply). The need for voting is a byproduct of this lack of vision, not a > requirement in its own right. We had the vision for quite a long time, even though we never officially stated it. Maybe because there was a general consensus about it, maybe because nobody asked. Now that there are many people in PHP with different backgrounds - and make no mistake, it is a great thing - people do disagree about what the vision is. I think we should keep with the vision of being simple and accessible, even if the more complex use cases will be a bit harder to implement. Some folks may disagree, and while I think they are wrong, I accept that there can be legitimate disagreement between us. I don't say "shut up" to them, I say "let's find something that we all could agree on". If we can not, I'd rather prefer the status quo than making it worse by making it too complex and too convoluted. > 1. "PHP Should Strive To Be A Full Featured Object Oriented Language". This is not a good vision, since nobody knows what is "full featured", or everybody knows and it is different for everybody. Most of the things you mention have very little to do with OO as such. Moreover, I see very little value in PHP fitting somebody's definition of "full featured language". I think our features should be driven by what is needed by majority of users, while keeping in sight the overall spirit of not overcomplicating things. Saying "we absolutely must have generators because all cool boys have them" makes little sense to me. Saying "we need generators because they make these frequent use cases easy and here's how we can integrate it into the language in a way that does not add unnecessary complications" - does make sense. Here we can disagree how frequent the cases are, and there can be different opinions on it, but at least we have a common ground on what we could have a common ground :) Saying "do it as I say or PHP is not full-featured" is not a good way to build common ground. > field for contributions and discussions. Rather than every developer > playing for themselves and saying "I hope this never happens", it puts > it in the context of "I don't believe this fits our vision". Note the > difference in tone between them. If it makes it easier, please replace "I hope this never happens" with "I don't believe this fits our vision" in my last response. > It's an ongoing joke about how abusive and unproductive the internals > list is. I for one am sick of it. And rather than keeping ignoring it This is coming from a man that just told me to shut up? Did I ever tell you to shut up? Did I publicly question your competence or assumed you don't know anything about the matter discussed? You complain about the list being abusive and yet you are the one who distributes abuse, as it appears to me. I agree, this needs to be fixed. Please be part of the solution, not of the problem. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #64777 — Adam Jon Richardson — 2013-01-09T19:26:59+00:00 URL: https://externals.io/message/64770#64777 · In reply to: #64770 > Stas, > > On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev wrote: > > > […] > > > 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. Anthony, I have a lot of respect for your expertise as a programmer (I follow your blog, and I've appreciated your work on the password hashing capabilities.) While I like your initiative, Stas was providing feedback on a proposal, and your opening was directed at him, personally. I doubt Stas is "out of touch with the reality of modern development." What it does potentially speak to is the difference in visions you both have for PHP. > If you have solid feedback to provide, then provide it. But saying "We're > supposed to be simple language for doing cool stuff on the web" shows you > have no idea what people have been doing (or don't want to acknowledge) > with the language for the past 5 years. It seems like Stas responds to many, many emails every day. He was even the ONE who provided commentary on my most recent idea (this shows his diligence.) Quoting him on one quick excerpt he typed among many to provide evidence that he has no idea what people have been doing again seems unfair, as I see Stas devote much time to providing feedback on internals threads. Last, I would suggest that even feedback as simple as "I don't want this in PHP" does have a place. Nothing comes for free. Every bit of additional functionality has the potential to slow PHP, both in terms of development, maintenance, and runtime. Declaring your belief that some pieces of functionality are better integrated as extensions is important feedback in terms of setting boundaries on the core capabilities of PHP. The Lua mailing list frequently has this sentiment expressed (as do many other mailing lists), and it doesn't mean that its core developers are out of touch. It just means you have to be working to set the boundaries somewhere. This all said, creating a vision statement for PHP seems like a nice idea to help guide the process. Perhaps that work would help guide where the boundaries for core should be considered. Again, thanks for the nice work on the password hashing API :) Adam --- ## #64779 — Anthony Ferrara — 2013-01-09T19:48:08+00:00 URL: https://externals.io/message/64770#64779 · In reply to: #64775 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 > go into programming. PHP is what a random Joe uses when he needs to whip > up a page and he's in "do it yourself" mind. PHP is what you expect > everybody to be able to handle, and everything to be able to run. It is > not to serve everybody, every use case and every possible need. Yes, we > try to extend the boundaries and do clever things - but sometimes we > have to make a choice. You can not be everything to everybody. And if > the choice between some complicated use-case that will be used by maybe > 1% of the users and even then will be buried in the guts of some huge > library and simplicity and accessibility of the language - I choose the > latter every time. Library writers are smart, they can work around it > and nobody but them will see it anyway. But turning the language into > Java wannabe would affect all the users. And most of them don't need > that, in my opinion. > 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. 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 contributions by. And that's the entire point of my call for a single, consistent and official vision... > That doesn't mean we should not improve and go forward. We should. But > we should do it consistent with yes - the vision of the language being > accessible and not overly complex. If you want rigid OO-pattern-driven > language - you have Java. If you want full mathematics power with full > mathematics complexity - you got Scala and Haskell and so on. There's > nothing wrong with them. They are just not PHP and PHP is not them. They > have their playground and we have ours. Having vision does mean > sometimes having to say "PHP is not X" and reject stuff because of that. Again, "PHP is not X" is rhetoric. Pure and simple. You could use that to reject *any* feature that we didn't explicitly invent. Which is the problem. I didn't hear that come up on the generators discussion ("PHP is not Python"). And that's why it's not useful as an argument. When discussing a specific feature, it's not a useful stick to measure by. And that's why it's a bad argument to put forth. I have feedback to provide and I provide it all the time. But if by > "solid" you mean agreeing with you, you're not getting that. Yes you do! And quite often you do it in a very good and constructive way. I applaud that. But you also provide it in a very destructive way at times. And that's what I'm asking you to please stop. For example: http://marc.info/?l=php-internals&m=135083835232016&w=2 While that's your opinion, the way you present it does not do anyone any good. We had the vision for quite a long time, even though we never > officially stated it. > Then it's not a vision in the context that I'm suggesting. > > […] > > This is not a good vision, since nobody knows what is "full featured", > or everybody knows and it is different for everybody. It was an example of a possible vision statement. Nothing more. I wasn't even suggesting it was a good one, or one we should adopt. Just something to show as an example. > > […] > > If it makes it easier, please replace "I hope this never happens" with > "I don't believe this fits our vision" in my last response. I only think that makes sense if we have an official, stated vision. But yes, that would make it far easier. > > […] > > This is coming from a man that just told me to shut up? Did I ever tell > you to shut up? Did I publicly question your competence or assumed you > don't know anything about the matter discussed? You complain about the > list being abusive and yet you are the one who distributes abuse, as it > appears to me. I agree, this needs to be fixed. Please be part of the > solution, not of the problem. I didn't tell you to shut up. I said to shut up with the rhetoric. There's a difference. I value your opinions. I really do. I quite often disagree, but that's fine (good actually). What I don't value at all are the BS remarks about "PHP is not java" and "I never want to see this in PHP". They don't do any good but to dilute constructive discussions. The reply thread that I quoted your line from has some very good contributions by you to it. But that last one did not need to be sent, as it provided absolutely nothing constructive to the post. 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). I used that line to open this thread because it was something I am passionate about. And because I see it as proof of the disconnect between the people in the discussions. That's why I wrote this thread how I did. One thing I will apologize for is the following note: > you're completely and utterly out of touch with the reality of modern development. While I do believe that you are out of touch with what's been going on in the user-land of PHP trends over the past 5 years, the way I wrote it was definitely not constraining to that area. So I'm sorry for making it sound like you're separated from reality... Anthony --- ## #64780 — Rasmus Lerdorf — 2013-01-09T19:52:35+00:00 URL: https://externals.io/message/64770#64780 · In reply to: #64779 > 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 contributions by. And that's the entire point > of my call for a single, consistent and official vision... They don't seem different to me, and the first one is the documented statement that has been the first thing people see on http://php.net for years and years. You can add "simple and practical" to mine or add "general purpose" to the Stas one and it doesn't conflict in any way. -Rasmus --- ## #64781 — Levi Morrison — 2013-01-09T19:52:53+00:00 URL: https://externals.io/message/64770#64781 · In reply to: #64775 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. --- ## #64782 — Clint Priest — 2013-01-09T19:55:05+00:00 URL: https://externals.io/message/64770#64782 · In reply to: #64770 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. In short I think PHP lacks direction because "everyone has a voice" and "nobody has authority." In the last two years of working on property accessors I think I have found this to be the most dis-tasteful aspect of working on the project, no person, document or group that leads. > Stas, > > On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev wrote: > > > […] > > 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 never want this, then > don't contribute to the discussions at all. > > If you have solid feedback to provide, then provide it. But saying "We're > supposed to be simple language for doing cool stuff on the web" shows you > have no idea what people have been doing (or don't want to acknowledge) > with the language for the past 5 years. > > And that brings us to the root of the problem. Discussion like this is due > to the fact that there's no clear "official" vision for PHP. Each > participant brings their own concept and vision, and treats it like it's > everyone else's vision as well (which is the exact reason for your reply). > The need for voting is a byproduct of this lack of vision, not a > requirement in its own right. > > For all the problems that a Benevolent Dictator brings to a project, this > is not one of them. This is a case where a dictator that sets the vision in > clear and unambiguous terms would actually improve the process quite > significantly. Instead of worrying about voting or everyone doing what they > want, there's a benchmark to measure proposals against. > > For example, imagine these different visions for PHP (which I know for a > fact are shared on this list): > > 1. "PHP Should Strive To Be A Full Featured Object Oriented Language". > > In this context frame, things like annotations, mixins, generators, etc > become the focus. As would moving the error handler to exceptions. And a > host of other changes (boxing primitive types when treated like an object, > etc). Adding functions like array_get_whatever would be frowned upon... > > 2. "PHP Should Remain A Procedural Language WIth Some OO Features" > > In this context frame, a lot of the stuff I said above goes away. And > adding new array functions would be the norm. And it's plain to tell that > exceptions shouldn't be implemented for errors. > > 3. "PHP Should Be Implementation Neutral, and Support > All Paradigms Equally". > > This is as close to the current implementation as we currently are. We > support procedural, OOP and functional constructs. But how deep does it go? > Where's the line. > > 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 hope this never happens", it puts it in the > context of "I don't believe this fits our vision". Note the difference in > tone between them. > > It's an ongoing joke about how abusive and unproductive the internals list > is. I for one am sick of it. And rather than keeping ignoring it (or > walking away), I'd rather see it fixed. > > Anthony > -- -Clint --- ## #64788 — Larry Garfield — 2013-01-09T22:27:53+00:00 URL: https://externals.io/message/64770#64788 · In reply to: #64782 > 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. In short I think PHP lacks direction because "everyone > has a voice" and "nobody has authority." > > In the last two years of working on property accessors I think I have > found this to be the most dis-tasteful aspect of working on the project, > no person, document or group that leads. Relevant: http://www.jofreeman.com/joreen/tyranny.htm --Larry Garfield --- ## #64791 — Adam Harvey — 2013-01-10T01:39:06+00:00 URL: https://externals.io/message/64770#64791 · In reply to: #64774 > 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 detailing your concerns, and say "Based on that, I don't like > it". Amaury has a point, though. Personally, I don't think annotations belong in PHP. Now, I can explain why based on my use of Symfony and Doctrine, but that suggests that I'm going to change my mind when truthfully, I'm almost certainly not going to — it's a difference of philosophy, rather than something specific to the RFC or the patch. So my dilemma is this: how do I voice this (without simply a drive-by -1 vote, which isn't really helpful either, and is overly discouraging to the people who've put a lot of work in to polish the feature up) without being shouted down for being unhelpful or uncivil? Adam, who isn't touching the rest of this discussion with a ten foot pole. --- ## #64793 — Tyler Sommer — 2013-01-10T02:05:21+00:00 URL: https://externals.io/message/64770#64793 · In reply to: #64791 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.nabble.com/Annotations-own-implementation-or-Doctrine-Commons-td4655427.html To say "they shouldn't be part of PHP" is fine, but it's too late for that. Annotations are already here. Are we going to just ignore this fact and hold back what a very significant portion of the community wants to see because it conflicts with some ambiguous master plan for PHP? Cheers. > > > […] > can > > […] > > Amaury has a point, though. > > Personally, I don't think annotations belong in PHP. Now, I can > explain why based on my use of Symfony and Doctrine, but that suggests > that I'm going to change my mind when truthfully, I'm almost certainly > not going to — it's a difference of philosophy, rather than something > specific to the RFC or the patch. > > So my dilemma is this: how do I voice this (without simply a drive-by > -1 vote, which isn't really helpful either, and is overly discouraging > to the people who've put a lot of work in to polish the feature up) > without being shouted down for being unhelpful or uncivil? > > Adam, who isn't touching the rest of this discussion with a ten foot pole. --- ## #64794 — Sherif Ramadan — 2013-01-10T02:08:46+00:00 URL: https://externals.io/message/64770#64794 · In reply to: #64779 > > > 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 by wrong or improper use or action; especially : corrupt (2) using harsh insulting language ; characterized by or serving for abuse ; physically injurious By what definition of the word could abusive ever be construed as constructive? I posit that you are far from constructive based on the nature of this thread now revolving around your direct personal attack towards someone and veering off from any real progress on internals matters. One courtesy I will offer you that you -- yourself -- have not offered your peers is the acknowledgement of your own contributions and opinions among the rest of the contributors in an impartial manner. You, like everyone contributing to PHP, have opinions, motives, and convictions. That does not mean one should put their own opinions, motives, and convictions above the group in order to make sure they are heard. This is the equivalent of someone in the middle of a rioting crowd pushing people out of the way in order to make sure they hear his plead for calmness and order (do as I say not as I do). You certainly aren't setting a good example if those are you motives. This talk of BDFLs you are so incumbent to reiterate has been portrayed by you in a biased light. You are forgetting to mention all the things BDFLs in other open source projects do that you yourself are here asking us not to do. Like using arguments such as "Language X is not language Y", which I've heard Guido van Rossum say at a public talk on Python 3000. They also have every right to "put their foot down" without allowing any room for discussion as I've seen Linus Torvalds do on the Linux Kernel mailing list. (Linus telling someone to STFU https://lkml.org/lkml/2012/12/23/75). You seem to have dictatorship sorely confused with visionary leadership. If even this were not the case then you should not be making those arguments of vision and BDFLs interchangeably. Anthony, I appreciate your remarkable brilliance as a developer and I admire your talent. However, one thing I've learned in my time as a developer is that you never want the guy that's incredibly talented to stop asking questions and start giving all the answers. There's a reason for this. You don't want someone like that to get too cocky and believe they already know it all and that all they can do now is teach others. It is true that you are knowledgeable, but that does not preclude that you can't learn from others on this list despite all of the shortcomings the list has to offer. It is true that you are wise, but it does not mean that you have grown so wise that you outwit the masses. I hear people saying PHP has a vision that is web-centric and focused on making it possible for both the "weekend-warrior" as well as the "9-to-5 guy" to make it in web development. You see that this vision is lacking, or unrefined, or even completely diluted to the extent that it is not a vision (and for whatever reason). That's fine. How are you solving this issue? I don't hear anyone on this list backing you on this thought. A good leader does not lead by wandering ahead of the crowd and telling them what will come. A good leader walks among the crowd and asks them what they want. I don't see any consensus gathering behind you. Perhaps these group-thinks you allude to are really just people's honest opinion? Who knows. The point is you should try to focus more on slowly building up consensus if you feel your ideas are that valuable, and people will ultimately follow if this is true. As opposed to making waves. Sherif, Mr. Always happy never grumpy! --- ## #64795 — Yahav Gindi Bar — 2013-01-10T02:09:22+00:00 URL: https://externals.io/message/64770#64795 · In reply to: #64793 > 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.nabble.com/Annotations-own-implementation-or-Doctrine-Commons-td4655427.html > > To say "they shouldn't be part of PHP" is fine, but it's too late for that. > Annotations are already here. Are we going to just ignore this fact and > hold back what a very significant portion of the community wants to see > because it conflicts with some ambiguous master plan for PHP? > > > Cheers. > > > > > […] > to > > […] > civil > > […] > pole. > > […] > You've touched the main point I think we should consider - we're contributing for the community - if the community wish so much that feature, that they've hacked some other (doccomment) in order to get their desired result - I think that this is the best evidence that we should include that in the language - the community really wish to have it. --- ## #64796 — Adam Harvey — 2013-01-10T02:28:23+00:00 URL: https://externals.io/message/64770#64796 · In reply to: #64793 > 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 specifically, rather than the broader userland community, since we're on Internals. > To say "they shouldn't be part of PHP" is fine, but it's too late for that. > Annotations are already here. Are we going to just ignore this fact and hold > back what a very significant portion of the community wants to see because > it conflicts with some ambiguous master plan for PHP? I don't have a master plan (that would be the part of this thread I'm not touching), but if it's a poorly thought out feature, sure. Pretty much every major project out there uses a unit testing framework and ORM: does that mean we should also be including equivalents for PHPUnit and Doctrine in core? Basically, I think the trend towards configuration as behaviour is an antipattern that results in less readable, harder to debug code. Having said that, the beauty of our userland being a set of communities is that each community can make their own decisions — since the good folks behind Doctrine have written an excellent annotation parser, those who want to go that way can, but it doesn't mean PHP has to go out of its way to encourage it. Or, to put it another way, not everything has to be a language feature. That way lies Perl. Adam --- ## #64797 — Tyler Sommer — 2013-01-10T02:52:05+00:00 URL: https://externals.io/message/64770#64797 · In reply to: #64796 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. > > > […] > > To explain what I meant by "PHP", since I think we're arguing > semantics there: I mean php-src specifically, rather than the broader > userland community, since we're on Internals. > > > […] > that. > > […] > hold > > […] > because > > […] > > I don't have a master plan (that would be the part of this thread I'm > not touching), but if it's a poorly thought out feature, sure. Pretty > much every major project out there uses a unit testing framework and > ORM: does that mean we should also be including equivalents for > PHPUnit and Doctrine in core? > > Basically, I think the trend towards configuration as behaviour is an > antipattern that results in less readable, harder to debug code. > Having said that, the beauty of our userland being a set of > communities is that each community can make their own decisions — > since the good folks behind Doctrine have written an excellent > annotation parser, those who want to go that way can, but it doesn't > mean PHP has to go out of its way to encourage it. > > Or, to put it another way, not everything has to be a language > feature. That way lies Perl. > > Adam --- ## #64798 — guilhermeblanco@gmail.com — 2013-01-10T05:31:09+00:00 URL: https://externals.io/message/64770#64798 · In reply to: #64797 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 different from Traits or Aspects. They all include new tokens on parser, they all "slow down" (as you keep claiming everytime) and they all have specific niches to be used. Now I wonder how Traits got IN, Aspects got rejected in 2007 and Annotations is being a nightmare to you guys. Or will you guys claim that Traits will be vastly used? 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 like yaml_file are out. If this is a clear vision, sorry, I'm probably too dumb to understand. OOP is a trend in PHP and no matter what you guys try to do, procedural support is quite decent, OOP is getting there aswell as functional. We're just trying to improve OOP, which lacks of many different features that many users ask and keep hitting the wall. You guys may now know, but 9 out of 10 most used frameworks are entirely OO. It's a shame that because Yahoo code is procedural (worked at Yahoo already), SugarCRM code has terrible OO decisions (I've seen its code), adopting exceptions handling !!!in July 2012!!! that makes you guys say there's no need to improve on OO features that community is claiming. I implemented support in 2009, asked for this in 2010 and since then I've seen only in this ML the same feature being asked not by me at least more 10 times. Isn't it a sign of a feature demand? > 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. > > > > > […] > the > > […] > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #64799 — Levi Morrison — 2013-01-10T05:36:18+00:00 URL: https://externals.io/message/64770#64799 · In reply to: #64798 > 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 like yaml_file are out. A bit off-topic, but I'm wondering how the SPL datastructures ever passed peer review . . . which does bring me to a relevant topic: We need to make sure we release quality implementations of whatever it is we do. --- ## #64800 — Stas Malyshev — 2013-01-10T06:20:31+00:00 URL: https://externals.io/message/64770#64800 · In reply to: #64779 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 once and for all, are you sure it is what you want? It is clear we disagree on many things. Suppose I wrote a document that describes how I see PHP should be, and it will be accepted as a "vision". Would you then say it is the right thing to do and agree with me completely as far as the "vision" document goes? Would you expect everybody else to do so? Probably not. So while we can have some vague "mission statement", there would always be disagreement on specific questions, and only way you can avoid that is to exclude some side of the debate. We can have a vision, but not one that would be used to avoid disagreement and discussion. > While they both have "web" in them, they provide very different goals > and metrics with which to gauge contributions by. And that's the entire > point of my call for a single, consistent and official vision... Can you give me some examples of modern languages like PHP having "official visions" like that? I'd really like to understand what kind of official vision you have in mind. Some document examples would help. > Again, "PHP is not X" is rhetoric. Pure and simple. You could use that > to reject *any* feature that we didn't explicitly invent. Which is the Maybe I could, but I never did and never intend to, and you know that I have supported and participated in discussions of number of features that I did not explicitly invent. It is not about me. It is about what is a good fit for PHP and what is not. I think some complex features are not a good fit for PHP and that's my "vision". > Yes you do! And quite often you do it in a very good and constructive > way. I applaud that. But you also provide it in a very destructive way > at times. And that's what I'm asking you to please stop. For example: I think the direction such changes take PHP is wrong, and I see no reason why I need to stop saying that. I think adding such syntax would make PHP code look convoluted and would significantly impair ability of the developers to understand what's going on. It may be a perfect fit for a couple of ORM-like use cases, but I think it's not enough to make it part of the general PHP language. I hope we can find common ground that can be useful for ORM folks but still not over-complicated and does not develop into additional sub-language with some weird syntax driven mainly by "which symbol didn't we use yet?" But if it is the only way to do it, then I'd rather not. > While I do believe that you are out of touch with what's been going on > in the user-land of PHP trends over the past 5 years, the way I wrote it Your belief is wrong, and let's leave it at that. It's really not about me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #64801 — Stas Malyshev — 2013-01-10T06:49:28+00:00 URL: https://externals.io/message/64770#64801 · In reply to: #64798 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 developer, how it can be seen by novice PHP developer, how easy is to understand what's going on, how much impact it would make on performance and robustness of the language, how easy or hard would be for tools to support it, etc. etc. - and then discuss with authors and decide if I'd like to have such thing or not. > I wonder how Annotations is different from Traits or Aspects. I'm not sure what you mean by Aspects, but traits are different from what was proposed as annotations because they are much simpler both conceptually (you just put a couple of methods from one class to another, same thing you do with inheritance but without full-blown OO "is-a" contract) and syntactically. If annotations were at the same level, I'd not have much problem with them, not at all. However, what is proposed is more akin to sub-language, with its own syntax, complex expressions, nested object instantiations and all this has to happen in some weird space which is both code and not code. And of course it should also have syntax that is both different from any other language that does the same, looks like completely different syntax in at least two other popular programming languages and two popular markup languages, and is chosen by principle of "which symbol didn't we use yet?". This seems to me a wrong way to do it. Not because I'm opposed to the idea in principle, but because I'm opposed to how it is done. > Or will you guys claim that Traits will be vastly used? I have no idea. We will see. How can I know what a million of people will be doing? > 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 like yaml_file are out. I'm not sure what you're getting at here. If you think we need to add YAML extension to core packages, please write an RFC, explain why is this extension good enough and required, have a vote and we'll see. I'm not sure why you're bringing it in this topic. > You guys may now know, but 9 out of 10 most used frameworks are entirely > OO. It's a shame that because Yahoo code is procedural (worked at Yahoo > already), SugarCRM code has terrible OO decisions (I've seen its code), > adopting exceptions handling !!!in July 2012!!! that makes you guys say > there's no need to improve on OO features that community is claiming. And I can't even begin to understand what you are talking about here. Nobody ever said there's no need to improve on OO features, and how SugarCRM code has anything to do with anything it's just beyond my comprehension. That doesn't mean we need to get anything any OO language has into PHP. Some of it is good for PHP, some of it would be better done differently. > 10 times. Isn't it a sign of a feature demand? I know that some folks want to have syntax like this: @MyApp\Acl({ "allow"=@MyApp\Acl\Allow({"john"="read", "joe"="write"}), "deny"=@OtherApp\Acl\Deny(default="*", log=true) }) and even more complex to be part of PHP function and property definitions. I think it is misguided on multiple levels. That does not mean some metadata support won't be useful - it probably would be. But not this way. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #64803 — Lester Caine — 2013-01-10T07:39:59+00:00 URL: https://externals.io/message/64770#64803 · In reply to: #64798 guilhermeblanco@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 in. I'd use the past tense there ... And I'll get beaten around the head again. PHP is a very nicely modular 'framework' on top of which many other views of the world have now been built. We DON'T need to load a lot of the recent developments ... we don't need to use them. Personally I don't load any MySQL related extensions since I don't have MySQL loaded. APC is replaced by eaccelerator which continues to work well for me (currently!). I've use phpdocumentor since I started with PHP because that was what all of the libraries USED internally to model/document the API, and since I used Eclipse as my IDE for C/C++ code, PHPEclipse was a natural progression and also uses the docblock information to provide in-line type hinting and a lot of the information that people are now clamouring to build in to the 'language'? I can understand some of the drives to 'new features', but I know I'm not alone in feeling rail-roaded into having to accept changes that are just detracting from writing code. Perhaps we can ignore 'e_strict' but the fundamental problem doing that is that moving 5.2 based code to 5.5 is simply not practical. Setting up a system that will run 5.2 code cleanly on a 5.4 configuration is only practical if you have a completely different set-up for clean 5.4 code! We NEEDED a better vision 5 years ago :( Now we need to manage the fallout and I know I keep banging on about it, but over 50% of user land are STILL using 5.2! Only 1.8% have 5.4 running with the main movement over the last few months TO 5.3 simply because that is the easiest way for ISP's to support their customers. ( http://w3techs.com/technologies/details/pl-php/5/all ) Bolting more and more facilities into core because a few users have the backing to force them in does not help the vast majority of user-land users who don't need those facilities. The argument that they need to be in the core so that ISP's will provide them probably highlights the whole problem? If your application needs some particular 'extension' to work then shouldn't that be part of the 'application' rather than the 'infrastructure'? Isn't the fact that one can add to PHP your own view of the world the whole point here. However it's also the Achilles heel so there ARE now large groups of people 'doing their own thing' and pulling things in a lot of different ways? Not everybody wants the Symphony/Doctrine/ORM view of the world. We are happy with using the database engine as the persistence layer, and a good abstraction layer as the interface ... code written 10 years ago still works ... or should do :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #64805 — Rafael Dohms — 2013-01-10T08:31:43+00:00 URL: https://externals.io/message/64770#64805 · In reply to: #64791 > > So my dilemma is this: how do I voice this (without simply a drive-by > -1 vote, which isn't really helpful either, and is overly discouraging > to the people who've put a lot of work in to polish the feature up) > without being shouted down for being unhelpful or uncivil? > > In my humble opinion, if your only "argument" is a -1, the don't be part of the discussion, but rather be a vote when (and if) the RFC goes to a vote. There are 2 moments to express yourself: the discussion, the vote. In the discussion phase I believe opinion should be expressed with solid concerns. Performance issues, bad syntax, is it relevant or not, etc. A simple "i don't like it" does not add, so it can be ommited. The voting is where you can simply say: i don't want this regardless of the syntax intent or how many unicorns it provides. That is what i do. -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://wwwamsterdamphp.nl --- ## #64806 — Martin Keckeis — 2013-01-10T08:36:56+00:00 URL: https://externals.io/message/64770#64806 · In reply to: #64803 The usage statistic is easy explained... Long time there was no planned "release cycle" so nobody could plan to upgrade (especially hoster and linux distributions, ...) Another reason why many people stick with the old version is poor written software like WORDPRESS -.-. I would also like to see a vision like it was for PHP6....unicode support, namespaces, ... For annotations i cannot "vote", because i won't use them. Best regards Martin 2013/1/10 Lester Caine > guilhermeblanco@gmail.com wrote: > > > […] > > I'd use the past tense there ... > And I'll get beaten around the head again. > > PHP is a very nicely modular 'framework' on top of which many other views > of the world have now been built. We DON'T need to load a lot of the recent > developments ... we don't need to use them. Personally I don't load any > MySQL related extensions since I don't have MySQL loaded. APC is replaced > by eaccelerator which continues to work well for me (currently!). I've use > phpdocumentor since I started with PHP because that was what all of the > libraries USED internally to model/document the API, and since I used > Eclipse as my IDE for C/C++ code, PHPEclipse was a natural progression and > also uses the docblock information to provide in-line type hinting and a > lot of the information that people are now clamouring to build in to the > 'language'? > > I can understand some of the drives to 'new features', but I know I'm not > alone in feeling rail-roaded into having to accept changes that are just > detracting from writing code. Perhaps we can ignore 'e_strict' but the > fundamental problem doing that is that moving 5.2 based code to 5.5 is > simply not practical. Setting up a system that will run 5.2 code cleanly on > a 5.4 configuration is only practical if you have a completely different > set-up for clean 5.4 code! We NEEDED a better vision 5 years ago :( Now we > need to manage the fallout and I know I keep banging on about it, but over > 50% of user land are STILL using 5.2! Only 1.8% have 5.4 running with the > main movement over the last few months TO 5.3 simply because that is the > easiest way for ISP's to support their customers. ( http://w3techs.com/** > technologies/details/pl-php/5/**all) > > Bolting more and more facilities into core because a few users have the > backing to force them in does not help the vast majority of user-land users > who don't need those facilities. The argument that they need to be in the > core so that ISP's will provide them probably highlights the whole problem? > If your application needs some particular 'extension' to work then > shouldn't that be part of the 'application' rather than the > 'infrastructure'? Isn't the fact that one can add to PHP your own view of > the world the whole point here. However it's also the Achilles heel so > there ARE now large groups of people 'doing their own thing' and pulling > things in a lot of different ways? Not everybody wants the > Symphony/Doctrine/ORM view of the world. We are happy with using the > database engine as the persistence layer, and a good abstraction layer as > the interface ... code written 10 years ago still works ... or should do :( > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=**contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.**uk