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
Hi Stas,
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/
Hi all,
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
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
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.
-
It felt a bit too "magic" for me, with no real gain from an internal or
userland perspective. -
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:
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
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.
Here's my feedback for you on why i voted No.
It felt a bit too "magic" for me, with no real gain from an internal or
userland perspective.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: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
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
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. :)
cheers
Dan
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
Hi!
- 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
"Stanislav Malyshev" wrote in message news:54C533A4.3090706@gmail.com...
Hi!
- 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
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?
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
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.