Hello,
with two competing RFCs (has this ever happend before?) we are in an
interesting spot now, game theoretically. Just letting both RFC authors
open and close the votes will bias the votes just by nature of who starts
first.
My (potentially very wrong) armchair analysis of the timeline is (my game
theory university knowledge is very dusty):
We have 3 types of players, 1 RFC a author, 1 RFC b author, $n voters,
roughly (subjective opinion) split between STH v0.5, coercive STH and no
type hinting (40/40/20).
The first vote to end, will get 40% of votes. If we assume that there are
STH proponents that don't care about the implementation and only want the
feature, then they will start to switch their vote on the second RFC now,
pushing it over 66% like Andrea's RFC managed.
The likelihood of the second RFC winning, REGARDLESS which one that is, is
much higher. So both RFC authors have no incentive to start their vote
first, delaying the vote.
One solution could be both votes should be parallel. In this case the
likelihood of both failing is very high, because you cannot vote with a
preference here, you will vote yes for one and no for the other. In either
case, if both votes end at exactly the same time, I think this could get
some ebay sniping vote sswitch behavior.
So the best/fairest option might probably, vote for both combined in a
single vote. This makes the likelihood of acceptance very high, however it
will pick one or the other by 50%+1, which might be against the voting RFC.
In any case, funny problem :-)
greetings
Benjamin
I like it! That's what I proposed to Anthony (and Andrea before) before
Zeev presented their alternative, to held a double vote on the strict vs
weak feature. It was not met with much enthusiasm, hope they change their
minds with your proposal!
On Mon, Feb 23, 2015 at 5:43 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:
Hello,
with two competing RFCs (has this ever happend before?) we are in an
interesting spot now, game theoretically. Just letting both RFC authors
open and close the votes will bias the votes just by nature of who starts
first.My (potentially very wrong) armchair analysis of the timeline is (my game
theory university knowledge is very dusty):We have 3 types of players, 1 RFC a author, 1 RFC b author, $n voters,
roughly (subjective opinion) split between STH v0.5, coercive STH and no
type hinting (40/40/20).The first vote to end, will get 40% of votes. If we assume that there are
STH proponents that don't care about the implementation and only want the
feature, then they will start to switch their vote on the second RFC now,
pushing it over 66% like Andrea's RFC managed.The likelihood of the second RFC winning, REGARDLESS which one that is, is
much higher. So both RFC authors have no incentive to start their vote
first, delaying the vote.One solution could be both votes should be parallel. In this case the
likelihood of both failing is very high, because you cannot vote with a
preference here, you will vote yes for one and no for the other. In either
case, if both votes end at exactly the same time, I think this could get
some ebay sniping vote sswitch behavior.So the best/fairest option might probably, vote for both combined in a
single vote. This makes the likelihood of acceptance very high, however it
will pick one or the other by 50%+1, which might be against the voting RFC.In any case, funny problem :-)
greetings
Benjamin
On 23 February 2015 at 21:15, Albert Casademont Filella
albertcasademont@gmail.com wrote:
I like it! That's what I proposed to Anthony (and Andrea before) before
Zeev presented their alternative, to held a double vote on the strict vs
weak feature. It was not met with much enthusiasm, hope they change their
minds with your proposal!
Except a dual vote is probably not going to work in favour of strict vs. weak.
Why would anyone who wants purely strict vote for "Yes (strict)", when
they know that "Yes (weak)" is going to have the majority. It boils
down to voting Yes for something you don't want. I don't think it will
convert votes at all. If I wanted strict only and I was presented
with "Yes (strict)", "Yes (weak)", and "No" and could see the weak
vote winning by a clear margin, I would vote No.
-----Original Message----> From: Leigh [mailto:leight@gmail.com]
Sent: Tuesday, February 24, 2015 2:56 PM
To: Albert Casademont Filella
Cc: Benjamin Eberlei; PHP Internals
Subject: Re: [PHP-DEV] The Game Theory of Scalar Type Hint VotingOn 23 February 2015 at 21:15, Albert Casademont Filella
albertcasademont@gmail.com wrote:I like it! That's what I proposed to Anthony (and Andrea before)
before Zeev presented their alternative, to held a double vote on the
strict vs weak feature. It was not met with much enthusiasm, hope they
change their minds with your proposal!Except a dual vote is probably not going to work in favour of strict vs.
weak.Why would anyone who wants purely strict vote for "Yes (strict)", when
they
know that "Yes (weak)" is going to have the majority. It boils down to
voting
Yes for something you don't want. I don't think it will convert votes at
all.
If I wanted strict only and I was presented with "Yes (strict)", "Yes
(weak)", and "No" and could see the weak vote winning by a clear margin, I
would vote No.
Leigh,
There isn't a weak-only proposal on the table. There's the original one
(dual mode) and the coercive one. Both have both strict and dynamic
elements in them.
I think that what Anthony proposed about a week or so ago, of having both
votes, and if both pass 2/3 - have another vote to choose between them
(where a simple majority wins) - makes the most sense in this uncharted
territory.
I think that opening the votes at the same time is probably a good idea.
Zeev
-----Original Message----> From: Leigh [mailto:leight@gmail.com]
Sent: Tuesday, February 24, 2015 2:56 PM
To: Albert Casademont Filella
Cc: Benjamin Eberlei; PHP Internals
Subject: Re: [PHP-DEV] The Game Theory of Scalar Type Hint VotingOn 23 February 2015 at 21:15, Albert Casademont Filella
albertcasademont@gmail.com wrote:I like it! That's what I proposed to Anthony (and Andrea before)
before Zeev presented their alternative, to held a double vote on the
strict vs weak feature. It was not met with much enthusiasm, hope they
change their minds with your proposal!Except a dual vote is probably not going to work in favour of strict vs.
weak.Why would anyone who wants purely strict vote for "Yes (strict)", when
they
know that "Yes (weak)" is going to have the majority. It boils down to
voting
Yes for something you don't want. I don't think it will convert votes at
all.
If I wanted strict only and I was presented with "Yes (strict)", "Yes
(weak)", and "No" and could see the weak vote winning by a clear margin, I
would vote No.Leigh,
There isn't a weak-only proposal on the table. There's the original one
(dual mode) and the coercive one. Both have both strict and dynamic
elements in them.
I think that what Anthony proposed about a week or so ago, of having both
votes, and if both pass 2/3 - have another vote to choose between them
(where a simple majority wins) - makes the most sense in this uncharted
territory.
I think that opening the votes at the same time is probably a good idea.Zeev
--
Well, one thing that would help apart from opening them at the same
time is also making the results not public until the voting ends (but
I'm not sure if this isn't prohibited by the RFC voting process
guidelines).
Regards
Pavel Kouril
Leigh,
There isn't a weak-only proposal on the table. There's the original one
(dual mode) and the coercive one. Both have both strict and dynamic
elements in them.
I think that what Anthony proposed about a week or so ago, of having both
votes, and if both pass 2/3 - have another vote to choose between them
(where a simple majority wins) - makes the most sense in this uncharted
territory.
I think that opening the votes at the same time is probably a good idea.
Ahoy,
I know there isn't a weak-only proposal. Albert had previously
suggested that a single proposal (the dual-mode one) should have a
3-way vote to pick default behaviour, instead of a simple yes/no on
the whole proposal. In the spirit of game theory, this feels like a
way to get people to vote for something they don't want (all votes for
strict by default actually count as a vote for weak by default, which
we know would take the majority).
If that's not what he was referring to here, then I apologise, my mistake.
Leigh.
Hi all,
Am 25.02.2015 um 10:09 schrieb Zeev Suraski:
I think that what Anthony proposed about a week or so ago, of having both
votes, and if both pass 2/3 - have another vote to choose between them
(where a simple majority wins) - makes the most sense in this uncharted
territory.
but that is exactly what Benjamin predicted to fail according to game
theory. The only way this will work is to vote if some scalar type hints
should come in with 7.0 (with a 2/3 majority) and then have a 50%+1 vote
on which of both proposals. Otherwise the chance for either passing 2/3
majority is virtually zero.
Or you could create a three-way vote, both proposals together need 2/3
majority over no-votes and the proposals that gets more than the other
is chosen.
Greets
Dennis
Yep, that's what I suggested but Leigh did see a competitive advantage for
weak-type hints in any case because if strict won we would have weak hints
too if I didn't use the declare option. I can see that point even though it
was not made at all with the intention of favouring weak vs strict, I
really don't care much, I just want them (whichever flavour) for the future
JIT/AOP goodies that we may have.
So yeah, I am again suggesting the same as Dennis! :)
On Wed, Feb 25, 2015 at 12:23 PM, Dennis Birkholz dennis@birkholz.biz
wrote:
Hi all,
Am 25.02.2015 um 10:09 schrieb Zeev Suraski:
I think that what Anthony proposed about a week or so ago, of having both
votes, and if both pass 2/3 - have another vote to choose between them
(where a simple majority wins) - makes the most sense in this uncharted
territory.but that is exactly what Benjamin predicted to fail according to game
theory. The only way this will work is to vote if some scalar type hints
should come in with 7.0 (with a 2/3 majority) and then have a 50%+1 vote
on which of both proposals. Otherwise the chance for either passing 2/3
majority is virtually zero.Or you could create a three-way vote, both proposals together need 2/3
majority over no-votes and the proposals that gets more than the other
is chosen.Greets
Dennis
Or you could create a three-way vote, both proposals together need 2/3
majority over no-votes and the proposals that gets more than the other
is chosen.
Even that simplifies things perhaps a little too much?
The questions as I see them are ...
Scalar Type Hinting - yes/no
Type of hinting - weak/strict/other
If only weak hinting accepted, option to add strict anyway - yes/no
Changes to casting rules are a separate discussion?
Change casting - yes/no/partial (selected tidy-up)
--
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 Lester,
Am 25.02.2015 um 12:48 schrieb Lester Caine:
Or you could create a three-way vote, both proposals together need 2/3
majority over no-votes and the proposals that gets more than the other
is chosen.Even that simplifies things perhaps a little too much?
The questions as I see them are ...
Scalar Type Hinting - yes/no
Type of hinting - weak/strict/other
If only weak hinting accepted, option to add strict anyway - yes/noChanges to casting rules are a separate discussion?
Change casting - yes/no/partial (selected tidy-up)
that is perfectly fine, I just hope that you will not do two competing
votes that both need 2/3+1 majority. Then both will fail and we (again)
have no scalar type hints at all!
Thanks
Dennis
Hi Benjamin,
On Tue, Feb 24, 2015 at 1:43 AM, Benjamin Eberlei kontakt@beberlei.de
wrote:
with two competing RFCs (has this ever happend before?
There will be another one. DbC.
We will have vote only RFC for 2 competing RFCs if we have
DbC or not, then chose DbC by definition or annotation.
Anyway, Zeev's proposal is much better. IMHO. Since we don't
have RFC owner for older proposal, we may only have vote for
Zeev's proposal.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Anyway, Zeev's proposal is much better. IMHO. Since we don't
have RFC owner for older proposal, we may only have vote for
Zeev's proposal.
Did I miss something? Pretty sure Anthony is still owning the proposal
he has put forward.