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
Sorry, I missed the link to the RFC on the previous e-mail:
https://wiki.php.net/rfc/binary_string_deprecation
Best regards,
Pedro Magalhães
Sorry, I missed the link to the RFC on the previous e-mail:
https://wiki.php.net/rfc/binary_string_deprecationBest regards,
Pedro Magalhães
I'm +1 on this, conditional on the deprecation not being thrown if
token_get_all() is used. The RFC currently doesn't say whether this is the
case.
Nikita
Hi Nikita,
The deprecation notice is not thrown during token_get_all() calls.
Regards,
Pedro
Sorry, I missed the link to the RFC on the previous e-mail:
https://wiki.php.net/rfc/binary_string_deprecationBest regards,
Pedro MagalhãesI'm +1 on this, conditional on the deprecation not being thrown if
token_get_all()is used. The RFC currently doesn't say whether this is the
case.Nikita
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
rejected by a small margin, particularly when there doesn't seem to
have been any voices against it.
Please could anyone who voted no, illuminate the rest of us as to why
voting no was the correct option?
cheers
Dan
-----Original Message-----
From: Dan Ackroyd [mailto:danack@basereality.com]
Sent: Tuesday, February 14, 2017 8:22 PM
To: Pedro Magalhães mail@pmmaga.net
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String DeprecationHello 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 rejected by
a small margin, particularly when there doesn't seem to have been any
voices against it.Please could anyone who voted no, illuminate the rest of us as to why voting
no was the correct option?
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 do need a binary string notation, it sounds more than likely that we'll pick this one. I see no value at removing it even if there's a small chance we'll need it again.
I suspect that's why we also saw very little discussion - it's really a non-issue, but it goes both ways - I probably wouldn't add it if it wasn't in, but I don't see the logic in removing it now that it's in.
My 2c.
Zeev
-----Original Message-----
From: Dan Ackroyd [mailto:danack@basereality.com]
Sent: Tuesday, February 14, 2017 8:22 PM
To: Pedro Magalhães mail@pmmaga.net
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String DeprecationI thought this RFC was likely to pass easily.
It's always slightly unfortunate when RFCs are either accepted or rejected by
a small margin, particularly when there doesn't seem to have been any
voices against it.Please could anyone who voted no, illuminate the rest of us as to why voting
no was the correct option?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 do need a binary string notation, it sounds more than likely that we'll pick this one. I see no value at removing it even if there's a small chance we'll need it again.
For similar reasoning, I abstained from voting. Actually, I'm -0.1 on
the deprecation.
--
Christoph M. Becker
On Wed, Feb 15, 2017 at 2:11 PM, Christoph M. Becker cmbecker69@gmx.de
wrote:
-----Original Message-----
From: Dan Ackroyd [mailto:danack@basereality.com]
Sent: Tuesday, February 14, 2017 8:22 PM
To: Pedro Magalhães mail@pmmaga.net
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String DeprecationI thought this RFC was likely to pass easily.
It's always slightly unfortunate when RFCs are either accepted or
rejected by
a small margin, particularly when there doesn't seem to have been any
voices against it.Please could anyone who voted no, illuminate the rest of us as to why
voting
no was the correct option?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 do need a
binary string notation, it sounds more than likely that we'll pick this
one. I see no value at removing it even if there's a small chance we'll
need it again.For similar reasoning, I abstained from voting. Actually, I'm -0.1 on
the deprecation.--
Christoph M. Becker
Hi all,
Thanks for contributing to the discussion.
One week ago marked 10 years since the forward compatibility was
introduced(5.2.1). This deprecation would allow us to remove them in the
future if no implementation ever comes forward. If that implementation ever
comes, we could still revert this. I think it's important to mention that
this is not a removal, it's only the first step in that direction.
I understand the reasoning that "it doesn't hurt". However, I would argue
that for someone new to the language, this can potentially be confusing. On
the type juggling page, the forward compatibility is mentioned but - AFAIK
- nowhere else (also not on the page about the String type). Users are left
on their one to figure it out. Searching for "php binary string" leads only
to the pack/unpack pages and questions from confused users on StackOverflow.
Given how long ago this was introduced, and how it still produces no
effect, it seemed like a good time to start preparing for it's removal.
Best regards,
Pedro
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 disruption (admittedly to a small code base, but still)
without any upside.
--
Stas Malyshev
smalyshev@gmail.com
Hi,
On Wed, Feb 15, 2017 at 8:35 PM, Stanislav Malyshev smalyshev@gmail.com
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 everSame here. I just don't see what is improved by this removal. To me,
it's just disruption (admittedly to a small code base, but still)
without any upside.
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-effects to any
code that does use it today.
In other words, it's supposed to be providing forward compatibility, but
any attempt to actually utilize it may only result in a BC break.
It's not a function or class name, so nothing benefits from reserving it
either ... or am I missing something?
Cheers,
Andrey.
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 than not changing. TO
make a change, substantial benefit should be shown. To not make a
change, it is enough that this benefit is not shown.
Stas Malyshev
smalyshev@gmail.com
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-effects to any
code that does use it today.
In other words, it's supposed to be providing forward compatibility, but
any attempt to actually utilize it may only result in a BC break.It's not a function or class name, so nothing benefits from reserving it
either ... or am I missing something?
One of the many reasons why the Unicode PHP 6 project failed was that
this 'binary string' flag was introduced much too late to expect
developers to add it to their code in a realistic time frame. Even if
the subject is still bad memories for many of us, someone may want to
address it again in the future and, at this time, the 'binary string'
flag may become useful again. Actually, it might even be the only
positive thing to remain from this mess :). Combined with the fact that
it does not cause much confusion, I prefer keeping it.
The risk of future BC break for the code actually using it is minimal as
the meaning is clearly defined, and doesn't have to be redefined in the
future : such string must be considered as a collection of 8-bit
characters without any encoding/decoding, whatever the default way of
considering strings.
Regards
François
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 it is re-used.
However it could probably wait until there is a clear plan of what to
do with strings.
cheers
Dan
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://github.com/symfony/symfony/blob/8f65fc7ec1418593d433e39abb71d3959eb10a0b/src/Symfony/Component/HttpKernel/Kernel.php#L718
in Symfony.
It'd have been great if the future would've been freed from this edge case.
Too bad it has been rejected.
Regards,
Nicolas
Too bad it has been rejected.
The vote is still open until the 20th.
Regards,
Pedro
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 possible, would be for var_dump()
to print it in a readable format (e.g. hex encoded) by default.
I don't see any issues with forward compatibility either, any attempt to
re-add a 'b' later would exhibit the same behavior it does now, most likely.
- Davey
Too bad it has been rejected.
The vote is still open until the 20th.
Regards,
Pedro
On Thu, Feb 16, 2017 at 11:25 PM, Nicolas Grekas <
nicolas.grekas+php@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 edge
case - yet it must be dealt with if you want a correct parser in userland.
See e.g.
https://github.com/symfony/symfony/blob/8f65fc7ec1418593d433e39abb71d3
959eb10a0b/src/Symfony/Component/HttpKernel/Kernel.php#L718
in Symfony.
It'd have been great if the future would've been freed from this edge case.
Too bad it has been rejected.
I feel your pain... Dealing with binary string lexing is surprisingly
subtle. The linked code is a nice illustration, because it handles the
binary string case -- but only for b" and not B", which is also valid. I
had the same bug in PHP-Parser until recently :/
Nikita
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