Hello all,
The voting has been closed and the RFC is declined with 19-13 which is not
enough for the 2/3 required majority.
Thank you all for voting and for participating in the discussion.
Regards,
Pedro
On Thu, Feb 16, 2017 at 11:25 PM, Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Actually, there is a very nasty side effect to the "b" prefix: it
> complicates using the output from token_get_all. You have to be very
> experienced (i.e. have feel the pain really) to know about this rare
I personally think there is value in marking strings as binary using the
'b' even if PHP currently doesn't differentiate, from a developer
friendliness perspective. It shows intent, and informs the reader of what
to expect if they inspect the value.
If anything, the only change I'd make, if possib
>
>
> Too bad it has been rejected.
>
The vote is still open until the 20th.
Regards,
Pedro
Actually, there is a very nasty side effect to the "b" prefix: it
complicates using the output from token_get_all. You have to be very
experienced (i.e. have feel the pain really) to know about this rare edge
case - yet it must be dealt with if you want a correct parser in userland.
See e.g.
https:
On 16 February 2017 at 10:14, François Laupretre wrote:
>
> the 'binary string' flag may become useful again I prefer keeping it.
Interestingly, that's why I voted yes.
If we want the binary string to be re-purposed in the future it needs
to be deprecated in a version before the version that
Hi,
Le 15/02/2017 à 20:02, Andrey Andreev a écrit :
While that's an understandable argument, what happens if we flip it? Is
there any benefit to keeping it?
If it currently does nothing, and the only reason for keeping it is that it
may do something in the future ... Well, there will be side-ef
Hi!
> While that's an understandable argument, what happens if we flip it? Is
> there any benefit to keeping it?
Yes. Not having to change it :) Please note that the barrier for
changing something, especially in a mature software product like PHP,
especially in a core language, is way way higher
Hi,
On Wed, Feb 15, 2017 at 8:35 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > I can't speak for others, but for me, it's simply because there's no
> > reason to do it (remove it), while there may/might be a reason to
> > keep it going forward. Keeping it comes at zero cost, and if we ever
>
> Same
Hi!
> I can't speak for others, but for me, it's simply because there's no
> reason to do it (remove it), while there may/might be a reason to
> keep it going forward. Keeping it comes at zero cost, and if we ever
Same here. I just don't see what is improved by this removal. To me,
it's just dis
t; To: Pedro Magalhães
> >> Cc: internals@lists.php.net
> >> Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation
> >>
> >> I thought this RFC was likely to pass easily.
> >>
> >> It's always slightly unfortunate when RFCs are either
On 15.02.2017 at 13:52, Zeev Suraski wrote:
>> -Original Message-
>> From: Dan Ackroyd [mailto:dan...@basereality.com]
>> Sent: Tuesday, February 14, 2017 8:22 PM
>> To: Pedro Magalhães
>> Cc: internals@lists.php.net
>> Subject: Re: [PHP-DEV] [RFC][VOT
> -Original Message-
> From: Dan Ackroyd [mailto:dan...@basereality.com]
> Sent: Tuesday, February 14, 2017 8:22 PM
> To: Pedro Magalhães
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation
>
> On 3 February 2017 at 12:47
On 3 February 2017 at 12:47, Pedro Magalhães wrote:
> Hello internals.
>
> After a *very* quiet period of discussion, I have now opened the vote for
> the Binary String Deprecation.
I thought this RFC was likely to pass easily.
It's always slightly unfortunate when RFCs are either accepted or
r
Hello internals.
After a *very* quiet period of discussion, I have now opened the vote for
the Binary String Deprecation.
There is a single vote for accepting or rejecting the deprecation.
The voting phase will end on 2017-02-20 20:00 UTC.
Best regards,
Pedro Magalhães
15 matches
Mail list logo
