Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Vote results for default ctors RFC »

[RFC] Vote results for default ctors RFC

php.internals

Stas Malyshev

11 years ago
Hi! The vote for RFC https://wiki.php.net/rfc/default_ctor has been concluded, with the result of 27 vs. 20. Since 2/3 majority is required for acceptance, the RFC has been declined. I am a bit disappointed by the result, as I think it would be a good change, but I am much more disappointed by the fact that that 20 people voted against it and not even half of them - I would say maybe 1/5 of them - chose to participate in discussion even minimally and explain what is wrong with it in their opinion. I understand when everybody agrees there's no need of the flood of +1s, vote is enough, but disagreement by its nature is more diverse. I think not bothering to discuss and then just voting "no" with no explanation is not how the healthy RFC process should be working.
-- Stas Malyshev smalyshev@gmail.com

Matteo Beccati

11 years ago
Hi Stas, On 25/01/2015 09:07, Stanislav Malyshev wrote:
> I am a bit disappointed by the result, as I think it would be a good > change, but I am much more disappointed by the fact that that 20 people > voted against it and not even half of them - I would say maybe 1/5 of > them - chose to participate in discussion even minimally and explain > what is wrong with it in their opinion. I understand when everybody > agrees there's no need of the flood of +1s, vote is enough, but > disagreement by its nature is more diverse. I think not bothering to > discuss and then just voting "no" with no explanation is not how the > healthy RFC process should be working.
I was supposed to send an explanation after voting, but I forgot. Sorry about that. I initially was going to vote "yes" as I kind of liked the concept. What made me change my mind was the implementation decision. I fully understand the reasons behind a conservative approach, but I just didn't like the "magic" (doesn't exist, but it's ok to call it). I would have voted yes for the approach #1 as it looked more consistent, and #2 seemed to be slightly worse than what we have now. My 2c. Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/

Yasuo Ohgaki

11 years ago
Hi all, On Sun, Jan 25, 2015 at 5:21 PM, Matteo Beccati <php@beccati.com> wrote:
> On 25/01/2015 09:07, Stanislav Malyshev wrote: > >> I am a bit disappointed by the result, as I think it would be a good >> change, but I am much more disappointed by the fact that that 20 people >> voted against it and not even half of them - I would say maybe 1/5 of >> them - chose to participate in discussion even minimally and explain >> what is wrong with it in their opinion. I understand when everybody >> agrees there's no need of the flood of +1s, vote is enough, but >> disagreement by its nature is more diverse. I think not bothering to >> discuss and then just voting "no" with no explanation is not how the >> healthy RFC process should be working. >> > > I was supposed to send an explanation after voting, but I forgot. Sorry > about that. > > I initially was going to vote "yes" as I kind of liked the concept. What > made me change my mind was the implementation decision. I fully understand > the reasons behind a conservative approach, but I just didn't like the > "magic" (doesn't exist, but it's ok to call it). I would have voted yes for > the approach #1 as it looked more consistent, and #2 seemed to be slightly > worse than what we have now.
I liked the idea. PHP is dynamic language and user should be able to enjoy the "magic", IMHO. I also would like to know the reason why vote against a RFC. Without feedback, there is no improvement. Comment plugin to the wiki, perhaps? Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Lester Caine

11 years ago
On 25/01/15 08:07, Stanislav Malyshev wrote:
> I think not bothering to > discuss and then just voting "no" with no explanation is not how the > healthy RFC process should be working.
One thought I had was 'Why would I be adding a constructor is the parent did not require one?' Personally I would prefer - like with other strict element - that if I am overriding something which does not currently exist I get a warning. If the base library 'improves' things by adding one then I also need to know, so silently hiding it just seems wrong! The bug in my 'update from 5.2 crib sheet is NOT adding the constructor to the parent, and that is my starting point even if it's just an empty shell. As other e_strict additions often turn out.
-- 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

Paul Dragoonis

11 years ago
Hi Stas, Maybe a cool wiki feature addition is: once people vote they could optionally leave a comment right there on the wiki, which we could collect and read. Thoughts? Here's my feedback for you on why i voted No. 1) It felt a bit too "magic" for me, with no real gain from an internal or userland perspective. 2) I don't see a flood of people coming to the mailing list complaining about this feature, so I'm not compelled to want it in the language. As always, thanks for your efforts. On Sun, Jan 25, 2015 at 8:07 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

Peter Cowburn

11 years ago
On 25 January 2015 at 10:52, Paul Dragoonis <dragoonis@gmail.com> wrote:
> Hi Stas, > > Maybe a cool wiki feature addition is: once people vote they could > optionally leave a comment right there on the wiki, which we could collect > and read. Thoughts? >
That's what the mailing list threads are for, right? In the more distant past, we did used to have individuals' comments on ideas in the wiki. If we did want to go down that road again, (almost) everyone who can vote can edit the wiki page to add their own thoughts right now.

Dan Ackroyd

11 years ago
On 25 January 2015 at 11:26, Peter Cowburn <petercowburn@gmail.com> wrote:
> That's what the mailing list threads are for, right?
If someone has already said a reason on the list for why an RFC should be voted no, when someone else agrees with that reason it's not common for them to email, as it could be viewed as generating noise. Also having all the reasons why an RFC was declined in one place would make it easier to revisit RFCs in the future. It would allow people to see if RFCs were declined because people thought they were just a bad idea, or if there was a problem with a small detail of the RFC, without having to wade through email archives. However I think there is a strong risk of people having to give a reason why they voted no being abused, particularly if it is shown while the voting was taking place, as people could be harassed for choosing an 'invalid' reason to reject the RFC. cheers Dan

Peter Cowburn

11 years ago
On 25 January 2015 at 15:44, Dan Ackroyd <danack@basereality.com> wrote:
> On 25 January 2015 at 11:26, Peter Cowburn <petercowburn@gmail.com> wrote: > > That's what the mailing list threads are for, right? > > > If someone has already said a reason on the list for why an RFC should > be voted no, when someone else agrees with that reason it's not common > for them to email, as it could be viewed as generating noise. >
Any internals discussion thread can be viewed as generating noise. How are readers to know whether the one post mentioning a particular for/against reason has wider support/disapproval without people saying so in the central discussion thread(s)? If it were a "noise or nothing" decision, I'd rather have multiple people saying "+1" on a particular thought or idea *during the discussion phase* than everyone keeping quiet for fear of being "noisy". Of course, I'd really rather posts be slightly longer and well thought-out than "+1" too.
> > Also having all the reasons why an RFC was declined in one place would > make it easier to revisit RFCs in the future. It would allow people to > see if RFCs were declined because people thought they were just a bad > idea, or if there was a problem with a small detail of the RFC, > without having to wade through email archives. >
There's nothing, procedurally, preventing RFC authors from summarising the discussion around an RFC on the RFC's wiki page; say after a vote has been finished, or even before the voting period.
> > However I think there is a strong risk of people having to give a > reason why they voted no being abused, particularly if it is shown > while the voting was taking place, as people could be harassed for > choosing an 'invalid' reason to reject the RFC. >
I too fear the "that's a terrible reason to vote the way you did" knee-jerk reactions. Then again, I could merrily vote "yes" to every single RFC without raising a whiff of suspicion or ridicule. :)

François Laupretre

11 years ago
> De : Dan Ackroyd [mailto:danack@basereality.com] > > However I think there is a strong risk of people having to give a > reason why they voted no being abused, particularly if it is shown > while the voting was taking place, as people could be harassed for > choosing an 'invalid' reason to reject the RFC.
Some suggestions for a future hypothetical RFC software : - Individual votes are kept secret. Just make public the number of voters and overall result. Each voter sees its own vote. - Vote starts with RFC discussion. - A voter can modify its vote until vote closes. - Votes span a range from '-2' (completely disagree) to '+2' (fully agree). - A minimal number of voters (quorum) is required for an RFC to be approved. - and, most important, comments are stored with the RFC, and mirrored to the mailing list. Please comment. Even if we don't have it today, maybe we can agree on an objective for tomorrow. I was looking for such a software, as I thought such needs are very common among open source projects, but I didn't find anything convincing. The best solution I imagine would be github adding an optional voting feature to issues (would we need to restrict access to vote or would we accept anybody with a github account ?). Github issues already have almost everything we need, except voting. Cheers François

Stas Malyshev

11 years ago
Hi!
> 2) I don't see a flood of people coming to the mailing list complaining > about this feature, so I'm not compelled to want it in the language.
That's true for most features, and that's normal - in fact, I can't remember a feature or a fix where we had a flood of people coming to the list. And a pretty strange reason to refuse a new thing - nobody develops new things by sitting and waiting for people to complain enough about not having this exact thing. Apple didn't make iPhone because a lot of people came to them and asked them to make an iPhone. Of course, I'm not comparing my little RFC to a technological breakthrough, but the whole premise that new things can be made only when enough people complained about not having it sounds wrong to me.
-- Stas Malyshev smalyshev@gmail.com

Tony Marston

11 years ago
"Stanislav Malyshev" wrote in message news:54C533A4.3090706@gmail.com...
> >Hi! > >> 2) I don't see a flood of people coming to the mailing list complaining >> about this feature, so I'm not compelled to want it in the language. > >That's true for most features, and that's normal - in fact, I can't >remember a feature or a fix where we had a flood of people coming to the >list. > >And a pretty strange reason to refuse a new thing - nobody develops new >things by sitting and waiting for people to complain enough about not >having this exact thing. Apple didn't make iPhone because a lot of >people came to them and asked them to make an iPhone. Of course, I'm not >comparing my little RFC to a technological breakthrough, but the whole >premise that new things can be made only when enough people complained >about not having it sounds wrong to me.
Well said. One way of gauging if people have problems which would be solved by an RFC such as this would be to look in the bug database. A quick search using "constructor" yielded over 300 results. I didn't examine all of them, but several would have been solved with this RFC. Introducing something only when enough people have complained about not having it is not always the right way to go. When the motor car was invented it was not because there was a demand for motor cars. Everybody was using horses at the time, and if you asked them what they wanted they would have answered "faster horses".
-- Tony Marston

Levi Morrison

11 years ago
> I am a bit disappointed by the result, as I think it would be a good > change, but I am much more disappointed by the fact that that 20 people > voted against it and not even half of them - I would say maybe 1/5 of > them - chose to participate in discussion even minimally and explain > what is wrong with it in their opinion. I understand when everybody > agrees there's no need of the flood of +1s, vote is enough, but > disagreement by its nature is more diverse.
It was a fairly simple proposed change with a well-defined set of impacted change; what diversity of disagreement do you expect?

Stas Malyshev

11 years ago
Hi!
> It was a fairly simple proposed change with a well-defined set of > impacted change; what diversity of disagreement do you expect?
I've already have a number of reasons I haven't heard before, or didn't know their relative importance to people. I think hearing people out - not necessarily agreeing, but at least being aware of the differences - is a part of the healthy process, while silently turning your back is not. People may think it's "noise" - and it can be if done excessively - but I think it's an important function of the community.
-- Stas Malyshev smalyshev@gmail.com

Leigh

11 years ago
On 25 January 2015 at 08:07, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> I am a bit disappointed by the result, as I think it would be a good > change, but I am much more disappointed by the fact that that 20 people > voted against it and not even half of them - I would say maybe 1/5 of > them - chose to participate in discussion even minimally and explain > what is wrong with it in their opinion. I understand when everybody > agrees there's no need of the flood of +1s, vote is enough, but > disagreement by its nature is more diverse. I think not bothering to > discuss and then just voting "no" with no explanation is not how the > healthy RFC process should be working. >
My points were already covered I believe. In hindsight I should have added a "me too". I think that "might refactor one day" is a pretty flimsy excuse for a feature, and if you're going to refactor, that constructor will probably need some parameters passing anyway, so you still have to do the work. I'm in the camp that thinks if you call a method that doesn't exist, you've done something wrong (I particularly hate __call too). Leigh.