Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-20 Thread Pedro Magalhães
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


Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-16 Thread Nikita Popov
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 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


Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-16 Thread Davey Shafik
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

On Thu, Feb 16, 2017 at 2:36 PM, Pedro Magalhães  wrote:

> >
> >
> > Too bad it has been rejected.
> >
>
> The vote is still open until the 20th.
>
> Regards,
> Pedro
>


Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-16 Thread Pedro Magalhães
>
>
> Too bad it has been rejected.
>

The vote is still open until the 20th.

Regards,
Pedro


Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-16 Thread Nicolas Grekas
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


Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-16 Thread Dan Ackroyd
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 it is re-used.

However it could probably wait until there is a clear plan of what to
do with strings.

cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-16 Thread François Laupretre

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-15 Thread Stanislav Malyshev
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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-15 Thread Andrey Andreev
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 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.


Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-15 Thread Stanislav Malyshev
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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-15 Thread Pedro Magalhães
On Wed, Feb 15, 2017 at 2:11 PM, Christoph M. Becker <cmbecke...@gmx.de>
wrote:

> 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 <m...@pmmaga.net>
> >> 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 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


Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-15 Thread Christoph M. Becker
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 <m...@pmmaga.net>
>> 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 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


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-15 Thread Zeev Suraski


> -Original Message-
> From: Dan Ackroyd [mailto:dan...@basereality.com]
> Sent: Tuesday, February 14, 2017 8:22 PM
> To: Pedro Magalhães <m...@pmmaga.net>
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation
> 
> On 3 February 2017 at 12:47, Pedro Magalhães <m...@pmmaga.net> 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 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 


Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

2017-02-14 Thread Dan Ackroyd
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
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php