# Vote: Anonymous Classes - Thread: https://externals.io/message/69485 - Original archive: https://news-web.php.net/php.internals/69485 - Started by Joe Watkins on 2013-10-07T06:29:14+00:00 - Messages: 25 - 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 --- ## #69485 — Joe Watkins — 2013-10-07T06:29:14+00:00 URL: https://externals.io/message/69485#69485 Morning Chaps, I have opened the vote on anonymous classes, following on from conversations had in IRC, we have the option to postpone this until 5.7 ... Cheers --- ## #69486 — Pierre Joye — 2013-10-07T07:08:29+00:00 URL: https://externals.io/message/69485#69486 · In reply to: #69485 hi! > Morning Chaps, > > I have opened the vote on anonymous classes, following on from > conversations had in IRC, we have the option to postpone this until 5.7 ... Can you move it to the voting phase section please? -- Pierre @pierrejoye | http://www.libgd.org --- ## #69487 — Pierre Joye — 2013-10-07T07:09:57+00:00 URL: https://externals.io/message/69485#69487 · In reply to: #69485 hi, > Morning Chaps, > > I have opened the vote on anonymous classes, following on from > conversations had in IRC, we have the option to postpone this until 5.7 ... Also I do not always follow IRC discussions. What is the reasoning behind post pone this feature to an hypothetical 5.7? Or why not 5.6? Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #69488 — Michael Wallner — 2013-10-07T07:11:03+00:00 URL: https://externals.io/message/69485#69488 · In reply to: #69485 > Morning Chaps, > > I have opened the vote on anonymous classes, following on from > conversations had in IRC, we have the option to postpone this until 5.7 ... You could have done us laziers a favor and add the link: https://wiki.php.net/rfc/anonymous_classes#voting :) -- Regards, Mike --- ## #69489 — Joe Watkins — 2013-10-07T07:38:16+00:00 URL: https://externals.io/message/69485#69489 · In reply to: #69487 > hi, > > > > […] > > Also I do not always follow IRC discussions. What is the reasoning > behind post pone this feature to an hypothetical 5.7? Or why not 5.6? > > Cheers, > Morning Pierre, 5.6 remains an option ... I brought it up in IRC the other day and someone, I forget who, but recognized them at the time, said they'd rather see it in 5.7, then a few people joined in the discussion and I couldn't really argue with their reasoning. The main point was that even a simple patch can have a destabilizing effect, and we've already merged several "simple" patches into 5.6. I think it's a bit early to call time on 5.6 features, and I think features like this require quite some time for adoption and should be out as quickly as possible ... I don't really know what is best ... Moved to voting bit .. Sorry mike, thanks for posting link :) Cheers --- ## #69490 — Pierre Joye — 2013-10-07T07:48:35+00:00 URL: https://externals.io/message/69485#69490 · In reply to: #69489 > 5.6 remains an option ... > > I brought it up in IRC the other day and someone, I forget who, but > recognized them at the time, said they'd rather see it in 5.7, then a few > people joined in the discussion and I couldn't really argue with their > reasoning. > > The main point was that even a simple patch can have a destabilizing > effect, and we've already merged several "simple" patches into 5.6. > > I think it's a bit early to call time on 5.6 features, It is not and we should begin soon to branch 5.6 and go with the milestones planing to get it out in June. > and I think > features like this require quite some time for adoption and should be out as > quickly as possible ... I agree. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #69491 — Joe Watkins — 2013-10-07T08:15:00+00:00 URL: https://externals.io/message/69485#69491 · In reply to: #69490 > > > > […] > > It is not and we should begin soon to branch 5.6 and go with the > milestones planing to get it out in June. > > > […] > > I agree. > > Cheers, > Hi Pierre, Re: "It is not ..." You seem to agree :) If we should do it _soon_, and not _now_, then it is a _bit_ too early isn't it ?? The end of 2015 is very far away from the perspective of the PHP user; they are not engaged in learning what will be available in two years time, look at adoption rates. The anonymous classes patch is actually simple, I can't imagine that it will have a profound effect on the things around it ... Cheers Joe --- ## #69493 — Nikita Popov — 2013-10-07T09:46:11+00:00 URL: https://externals.io/message/69485#69493 · In reply to: #69485 > Morning Chaps, > > I have opened the vote on anonymous classes, following on from > conversations had in IRC, we have the option to postpone this until 5.7 ... > > Cheers > The "Include in PHP 5.7" voting option, does this mean that we already now decide to include it in 5.7 or does it mean that we wish to reevaluate the feature during the 5.7 cycle? Nikita --- ## #69494 — Joe Watkins — 2013-10-07T09:49:27+00:00 URL: https://externals.io/message/69485#69494 · In reply to: #69493 > > > > […] > > The "Include in PHP 5.7" voting option, does this mean that we already now > decide to include it in 5.7 or does it mean that we wish to reevaluate the > feature during the 5.7 cycle? > > Nikita > I'm not sure, whatever seems appropriate ... if we're going to say that it's too late for this to go in 5.6, then it can't be too early to decide it can go in 5.7 can it ?? Cheers Joe --- ## #69497 — Joe Watkins — 2013-10-07T10:13:22+00:00 URL: https://externals.io/message/69485#69497 · In reply to: #69494 > > > […] > I'm not sure, whatever seems appropriate ... if we're going to say that > it's too late for this to go in 5.6, then it can't be too early to > decide it can go in 5.7 can it ?? > > Cheers > Joe Morning Chaps, On the advice of many, I have restarted the vote, sorry for the inconvenience/confusion ... Cheers Joe --- ## #69498 — Peter Cowburn — 2013-10-07T10:20:35+00:00 URL: https://externals.io/message/69485#69498 · In reply to: #69497 > > Morning Chaps, > > On the advice of many, I have restarted the vote, sorry for the > inconvenience/confusion ... https://wiki.php.net/rfc/anonymous_classes#voting (re-link, for the lazy) The voting options changed from choosing a version ("5.6", "5.7") or rejecting… too a much simpler, yes/no for sticking this into master. Which branch/release the feature makes it into is something to be decided down the line (ultimately, by the RMs). > > Cheers > Joe --- ## #69500 — johannes@schlueters.de — 2013-10-07T11:49:28+00:00 URL: https://externals.io/message/69485#69500 · In reply to: #69489 > I brought it up in IRC the other day and someone, I forget who, but > recognized them at the time, said they'd rather see it in 5.7, then a > few people joined in the discussion and I couldn't really argue with > their reasoning. When I brought this up I was on my current primary rant. Even small additions to the language have an impact on tools, best practices, ... which have to be explored about how to use them and how those interact with each other. To be clear: I love anonymous classes, I always wanted them when using FilterIterator etc. (while meanwhile generators+closures might be a better tool for some of those use cases) But we are moving extremely fast in reshaping the language making it hard for our users, of which many -- in my assumption -- primarily want a stable platform, to keep up. Oh and talking about "stable platform". Current bug count: 3891 See also my previous message on that subject: http://news.php.net/php.internals/69093 johannes --- ## #69501 — Pierre Joye — 2013-10-07T14:08:56+00:00 URL: https://externals.io/message/69485#69501 · In reply to: #69500 On Mon, Oct 7, 2013 at 1:49 PM, Johannes Schlüter wrote: > Oh and talking about "stable platform". Current bug count: 3891 And most of them are not in the language per se but in extensions or some totally ignored (see #65486 for what where you are in charge :). Now, ranting on IRC is all good and shiny. Leading new RFC contributors to confusion and mess up a vote is something slightly less shiny. If you could raise your actual points on the list next time, during the discussion period, then we will not lose time trying to figure out what happened or what led him to propose such choices. Thanks. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #69502 — Sebastian Bergmann — 2013-10-07T14:40:20+00:00 URL: https://externals.io/message/69485#69502 · In reply to: #69485 > I have opened the vote on anonymous classes, following on from > conversations had in IRC, we have the option to postpone this until 5.7 The option to postpone for PHP 5.7 implies that there is already a deadline for PHP 5.6. Is there? --- ## #69503 — Joe Watkins — 2013-10-07T14:55:11+00:00 URL: https://externals.io/message/69485#69503 · In reply to: #69500 > > > […] > > When I brought this up I was on my current primary rant. Even small > additions to the language have an impact on tools, best practices, ... > which have to be explored about how to use them and how those interact > with each other. > > To be clear: I love anonymous classes, I always wanted them when using > FilterIterator etc. (while meanwhile generators+closures might be a > better tool for some of those use cases) But we are moving extremely > fast in reshaping the language making it hard for our users, of which > many -- in my assumption -- primarily want a stable platform, to keep > up. > > Oh and talking about "stable platform". Current bug count: 3891 > > See also my previous message on that subject: > http://news.php.net/php.internals/69093 > > johannes > > The observation that even a small patch has an impact, or can have an impact is valid. But then to talk about adoption time turns your reasoning a bit circular: adoption does take time, if we want for adoption to take place then the earlier a patch gets merged the better, regardless of the complexity of the patch. I did see your "rant", though it's not really a rant; perfectly valid observations. Still, I don't know what you hope to achieve by pointing out the differences between the development of C or Java, and PHP: progress plotted on a graph nobody would expect to see any kind of relationship or commonality between these languages. So while they are valid observations they aren't really relevant. The bug count is a bit shameful, some effort should obviously be spent on bugs ... Cheers Joe --- ## #69504 — Pierre Joye — 2013-10-07T15:03:53+00:00 URL: https://externals.io/message/69485#69504 · In reply to: #69502 > > > […] > > The option to postpone for PHP 5.7 implies that there is already a > deadline for PHP 5.6. Is there? There is a deadline for the next release yes, ~June 2014. Cheers, -- Pierre @pierrejoye | | http://www.libgd.org --- ## #69506 — johannes@schlueters.de — 2013-10-07T15:30:34+00:00 URL: https://externals.io/message/69485#69506 · In reply to: #69503 > The observation that even a small patch has an impact, or can have an > impact is valid. But then to talk about adoption time turns your > reasoning a bit circular: adoption does take time, if we want for > adoption to take place then the earlier a patch gets merged the better, > regardless of the complexity of the patch. The issue is not that we are adding a single patch the issue is that we recently change the language in a rapid pace. > I did see your "rant", though it's not really a rant; perfectly valid > observations. Still, I don't know what you hope to achieve by pointing > out the differences between the development of C or Java, and PHP: > progress plotted on a graph nobody would expect to see any kind of > relationship or commonality between these languages. So while they are > valid observations they aren't really relevant. It is the only metric I have to answer comments if the sort "oh, PHP is developing so slowly" while we are fast in changing the language. What we i.e. don't do is trying to adopt our "standard library" to new paradigms being introduced. Also after changing the language we don't really check how this impacts new languages features. Maybe generators have an impact on the way anonymous classes should be designed? etc. I guess most here look at this with a PHP 5.2/5.3 mindset, not 5.5 or at least 5.4. that all said: > The bug count is a bit shameful, some effort should obviously be spent > on bugs ... This is the actual point here: We as a community at large should imo focus more on fixing bugs instead of creating new ones. If we could spend more of the time we spend on discussing new things on actually fixing bugs instead it is my unproven subjective claim that we'd make more people happy than by any "syntax sugar". And again to be really clear: This is nothing directly related to this feature, this patch or even you, but a very general opinion/observation from my side based on my observations and my discussions with users about current state of things. With that: All from my side is said and I hope we can end this more general sub-thread and use the time better :-) johannes --- ## #69508 — Pierre Joye — 2013-10-07T16:20:50+00:00 URL: https://externals.io/message/69485#69508 · In reply to: #69506 On Mon, Oct 7, 2013 at 5:30 PM, Johannes Schlüter wrote: > > > > […] > > The issue is not that we are adding a single patch the issue is that we > recently change the language in a rapid pace. > > > […] > > It is the only metric I have to answer comments if the sort "oh, PHP is > developing so slowly" while we are fast in changing the language. We do not change the language. We improve it. Changing the language implies that one has to change his existing code or application to get them run on a new release. That's not the case between 5.4 and 5.5, and should not be between 5.5 and 5.6. However we are not fast or slow, we only fill gaps with other modern languages. > What we i.e. don't do is trying to adopt our "standard library" to new > paradigms being introduced. Also after changing the language we don't > really check how this impacts new languages features. Maybe generators > have an impact on the way anonymous classes should be designed? etc. I > guess most here look at this with a PHP 5.2/5.3 mindset, not 5.5 or at > least 5.4. That's a good point and that's why we have RFCs. We have to review the impacts of a new feature, discuss the possible issues (design, BC, etc.). > that all said: > > > […] > > This is the actual point here: We as a community at large should imo > focus more on fixing bugs instead of creating new ones. A project focusing only on fixing bugs and does not implement new features is a dead project, they only don't know it yet. > If we could > spend more of the time we spend on discussing new things on actually > fixing bugs instead it is my unproven subjective claim that we'd make > more people happy than by any "syntax sugar". I think it is somehow not correct to say that. My team participates in a lot of discussions, we test all RFCs, before they end in the voting phase, continuously. We fix bugs, tons of bugs. We report bugs too. And many other developers do so as well. On the other hand some developers discuss/argue a lot while not fixing bugs at all nor developing new features. There are also developers being better at developing new features rather than doing QA. That's all good and we should try to figure out a way to work better together instead of blocking each other. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #69531 — Paul Dragoonis — 2013-10-09T11:14:25+00:00 URL: https://externals.io/message/69485#69531 Hi Joe, Thanks for your hard work on anonymous classes. I voted no because I feel it's just adding more and more ways to achieve similar results and the syntax is just more sugary fluff to allow people to do things the wrong way. We've had a lot of new features in recent versions, i.e: traits, so I believe this isn't something PHP needs right now and PHP needs to focus on bug fixing and solidifying what we have right now. Thanks, Paul > > > > […] > > To anyone who has voted or will vote no; if you have voted no but > is something that could be done to the patch to change your mind, please do > speak up :) > > If you voted/will vote no and there's nothing that can change your > mind, I'd still be interested in hearing the reasoning ... > > This is a pretty quiet vote ... as this is the first RFC I have > put forward, I'd like a bit more feedback so I can avoid the avoidable in > the future ... > > > Cheers > Joe --- ## #69532 — Ferenc Kovacs — 2013-10-09T11:22:54+00:00 URL: https://externals.io/message/69485#69532 > > > > […] > > To anyone who has voted or will vote no; if you have voted no but > is something that could be done to the patch to change your mind, please do > speak up :) > > If you voted/will vote no and there's nothing that can change your > mind, I'd still be interested in hearing the reasoning ... > > This is a pretty quiet vote ... as this is the first RFC I have > put forward, I'd like a bit more feedback so I can avoid the avoidable in > the future ... > > > Cheers > Joe > > -- > > > > I have voted no based on the lack of support for serialization/unserialization, and I think that we agreed that without somehow naming the class, we can't support that, and having a name would defeat the purpose of this feature. I'm looking forward to nested classes though. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #69533 — Matthew Leverton — 2013-10-09T11:29:34+00:00 URL: https://externals.io/message/69485#69533 > This is a pretty quiet vote ... as this is the first RFC I have put > forward, I'd like a bit more feedback so I can avoid the avoidable in the > future ... > I'm not a voter, but I'd lean toward 'no' on this because a) I really dislike the syntax and b) it didn't seem to play 100% nicely with core PHP features (e.g. serialization). However, I do think there's a place for such a feature in PHP though (just take a look at SplHeap). I wish RFC voters had to leave a brief comment (even if from a canned list) on the voting page when voting 'no' because it would add a lot more transparency to the process. I know a lot of people do comment somewhere and I trust that they vote responsibly, but it's hard to put it all together at the end. -- Matthew Leverton --- ## #69534 — Joe Watkins — 2013-10-09T11:39:09+00:00 URL: https://externals.io/message/69485#69534 · In reply to: #69532 > > > > […] > I have voted no based on the lack of support for > serialization/unserialization, and I think that we agreed that without > somehow naming the class, we can't support that, and having a name would > defeat the purpose of this feature. > > I'm looking forward to nested classes though. > Tyrael, As mentioned in the RFC, there's nothing stopping you from serializing an anonymous class. Anonymous classes are named, they _have_ to be; they are named after the codepath (so file/function/class) prefixed with namespace where they are used ... so in fact there's nothing wrong with the vast majority of applications using serialization of anonymous class objects. Nested classes is more complicated than anonymous ones, if this doesn't get in on a vote I don't see nested classes getting in either; if the reason people are voting no is really that "we need to concentrate on bugs", then what is really the point in preparing another RFC before 5.6 is out in the wild ... I hear the syntax sugar thing ... but it's starting to wear a bin thin, it's a phrase thrown around without much justification or thought: Almost everything you add at the Zend level which requires some kind of syntax (so, pretty much everything) can be described as syntactic sugar. It is only a parser modification, but that should only make it more appealing, we aren't asking anything new of Zend ... In any case, I appreciate the input :) Cheers Joe --- ## #69535 — Ferenc Kovacs — 2013-10-09T12:18:50+00:00 URL: https://externals.io/message/69485#69535 · In reply to: #69534 > I have voted no based on the lack of support for > > […] > > As mentioned in the RFC, there's nothing stopping you from > serializing an anonymous class. > Anonymous classes are named, they _have_ to be; they are named > after the codepath (so file/function/class) prefixed with namespace where > they are used ... so in fact there's nothing wrong with the vast majority > of applications using serialization of anonymous class objects. > yeah, and you can't autoload that, and if you move the instanitation of an anonymous class the generated internal classname will be different. and that is all fine for handling the instance in that specific request, but makes any attempt to persist and restore really fragile. I also think that anonymous classes and functions should be similar in this sense, and currently we don't allow the serialization of Closure instances(but we do allow the serialization of create_function(), and I do understand why is that, but it is not what most people would guess), which is a bit sucky, because you have to remember, that closures work the same way as any other callable, except that it can't be serialized (but it can be json_encoded and it will result in an empty object). I think that having such restrictions, when something almost works the way one would expect is wrong. > > Nested classes is more complicated than anonymous ones, if this > doesn't get in on a vote I don't see nested classes getting in either; if > the reason people are voting no is really that "we need to concentrate on > bugs", then what is really the point in preparing another RFC before 5.6 is > out in the wild ... > anonymous classes and nested classes have a bit different usecases, hence supporter base, I think you shouldn't guess on the result for that based on the feedback on anonymous classes. > > I hear the syntax sugar thing ... but it's starting to wear a bin > thin, it's a phrase thrown around without much justification or thought: > Almost everything you add at the Zend level which requires some kind of > syntax (so, pretty much everything) can be described as syntactic sugar. It > is only a parser modification, but that should only make it more appealing, > we aren't asking anything new of Zend ... > I didn't bring up this point, but I do agree that having changes in the ZE/parser should be done with a good reason, and simply because it could have a much wider impact area and less people familiar with fixing those kind of bugs. > > In any case, I appreciate the input :) > and we appreciate your work on improving php. _o_ -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #69536 — Joe Watkins — 2013-10-09T12:29:30+00:00 URL: https://externals.io/message/69485#69536 · In reply to: #69535 Just quick note ... If you autoload a class which in turn unserializes an object of an anonymous class autoloading will not be invoked for the anonymous class ... It is compiled when you load the super / outer class ... Am out and about on phone ... I think these kinds of issues can be explained / resolved ... > > I have voted no based on the lack of support for > > […] > > yeah, and you can't autoload that, and if you move the instanitation of an > anonymous class the generated internal classname will be different. > and that is all fine for handling the instance in that specific request, > but makes any attempt to persist and restore really fragile. > I also think that anonymous classes and functions should be similar in > this sense, and currently we don't allow the serialization of Closure > instances(but we do allow the serialization of create_function(), and I do > understand why is that, but it is not what most people would guess), which > is a bit sucky, because you have to remember, that closures work the same > way as any other callable, except that it can't be serialized (but it can > be json_encoded and it will result in an empty object). > I think that having such restrictions, when something almost works the way > one would expect is wrong. > > > > […] > > anonymous classes and nested classes have a bit different usecases, hence > supporter base, I think you shouldn't guess on the result for that based on > the feedback on anonymous classes. > > > > […] > > I didn't bring up this point, but I do agree that having changes in the > ZE/parser should be done with a good reason, and simply because it could > have a much wider impact area and less people familiar with fixing those > kind of bugs. > > > > […] > > and we appreciate your work on improving php. _o_ > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu --- ## #69546 — David Soria Parra — 2013-10-12T19:10:36+00:00 URL: https://externals.io/message/69485#69546 · In reply to: #69533 Matthew Leverton schrieb: > > > I wish RFC voters had to leave a brief comment (even if from a canned > list) on the voting page when voting 'no' because it would add a lot > more transparency to the process. I know a lot of people do comment > somewhere and I trust that they vote responsibly, but it's hard to put > it all together at the end. It's a wiki page, all voters have edit rights. We can simply introduce a "vote reasoning" part.