Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83611
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEPJdunUN-=CwmQ4boLJ_OjNPrNna9iVLbAzPgOtcRKRjAt8jg@mail.gmail.com>
References: <CAEPJdunUN-=CwmQ4boLJ_OjNPrNna9iVLbAzPgOtcRKRjAt8jg@mail.gmail.com>
Date: Mon, 23 Feb 2015 22:15:34 +0100
Message-ID: <CAMA5aFYEj_5n1xxrvce1DxVVU4HJkwxQLNygbPQxhOxJJ1g+fg@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01419f865b9893050fc7e855
Subject: Re: [PHP-DEV] The Game Theory of Scalar Type Hint Voting
From: albertcasademont@gmail.com (Albert Casademont Filella)

--089e01419f865b9893050fc7e855
Content-Type: text/plain; charset=UTF-8

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
>

--089e01419f865b9893050fc7e855--