Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions

[Tim Starling]

On 30/06/18 11:44, Yasuo Ohgaki wrote:
> readline has license issue. I miss it but I wouldn't object for removing it.
> Let's use libedit for CLI by default and always.
> Issue may be who is going to do this. If nobody volunteers, I may do this.

The discussion is about the readline extension, which includes support
for both libedit and the GNU Readline library. You can't use libedit
without the readline extension.

-- Tim Starling

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

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions

[Yasuo Ohgaki]

On Fri, Jun 29, 2018 at 2:16 PM, Tim Starling 
wrote:

> On 20/06/18 05:46, Stanislav Malyshev wrote:
> > Hi!
> >
> >> Hi!
> >>
> >> I would like to open the vote for the RFC about cleaning up the
> >> unmaintained extensions:
> >>
> >> https://wiki.php.net/rfc/umaintained_extensions
> >> 
> >>
> >> The vote ends 2018-06-26 23:59 PDT.
> >>
> >>
> >> Just to be sure consequence of "readline" removal.
> >>
> >> With CLI, "php -a" and "history" works without readline?
> >> Does it work as dynamically loaded module?
> >
> > CLI can still use readline library. This would be about readline PHP
> > extension.
> >
>
> Actually, readline support in "php -a" is part of the extension. The
> extension hooks the SAPI module. See PHP_MINIT_FUNCTION(cli_readline)
> in readline_cli.c.
>
> Readline is the only extension in your list that I would be sad about
> losing. I use it every day, I guess a lot of devs do.
>

readline has license issue. I miss it but I wouldn't object for removing it.
Let's use libedit for CLI by default and always.
Issue may be who is going to do this. If nobody volunteers, I may do this.

--
Yasuo Ohgaki

Re: [PHP-DEV] json_encode() x-notation

[Sara Golemon]

On Fri, Jun 29, 2018 at 1:51 PM, David Rodrigues  wrote:
> Hello. I saw that JS supports the x-notation (\x40) and u-notation
> (\u0040), but PHP only supports u-notation. There some reason for that?
>
The TL;DR version AIUI, is that JSON strings are Unicode strings, so
any byte sequence in a JSON string must be valid UTF-8.  With \x
encoding, one could easily create byte sequences which are not valid
UTF-8.  Best practices tend to use an intermediate, binary-safe
encoding (such as base64) when needing to transfer octet streams.

-Sara

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

[PHP-DEV] json_encode() x-notation

[David Rodrigues]

​Hello. I saw that JS supports the x-notation (\x40) and u-notation
(\u0040), but PHP only supports u-notation. There some reason for that?

JSON.parse('"\x40"'); // => @
JSON.parse('"\u0040"'); // => @

While PHP:

json_decode('"\\u0040"'); // => @
json_decode('"\\x40"'); // => null (Syntax error)

The json.org really don't seems doc the x-notation version, but some pages
does: http://www.javascriptkit.com/jsref/escapesequence.shtml

The same is valid to json_encode('@'), it will stringify to '\u0040'
instead of the most simplified version '\x40'.

I don't know if there are some reason for that, but I think that, at least,
is reasonable to json_decode() supports that.

-- 
David Rodrigues

Re: [PHP-DEV] [RFC] User-defined object comparison

[Rowan Collins]

On 27 June 2018 at 19:24, Levi Morrison  wrote:

> This permits things such as NumPy to overload < to do an element-wise
> comparison of the members; something like this:
>
> np.array([1, 3, 5, 7]) < np.array([2, 1, 6, 6])
> // evaluates to np.array([true, false, true, false)
>


In my opinion, this is exactly the kind of messy operator overloading we
should avoid, but if we DO want it, then its purpose is to over-ride the
syntax, not the meaning, of the operator; so "overloaded <=>" would NOT be
the same as "overloaded comparison".

I think it's fairly crucial that this proposal is NOT just about
overloading operators, it's about overloading *behaviour* which occurs
throughout the language, and as such I think this statement from the RFC is
incorrect:

> __compareTo is equivalent to <=> and __equals is equivalent to ==

If someone implements __compareTo() just to give some domain-specific
meaning to the <=> operator, what will happen when someone passes those
objects to sort()? If someone decides they want to return an object from
__equals(), how will switch statements behave? And so on...

Because of that, I would much rather these functions did enforce a return
type. Note that __toString() generates an error for an incorrect return
type when used, and __sleep() raises a Notice and serializes Null instead
of the object. I think __compareTo() and __equals() could act more like a
return type hint, and either throw a TypeError straight away, or attempt to
coerce to the correct type and throw a TypeError on failure.

Then, if we want the ability to override the <=> operator specifically,
that can be added later, and users can return whatever type they want
without breaking all the other places where __compareTo() is called.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions YasuoOhgaki

[Andrey Andreev]

Hi again,

On Fri, Jun 29, 2018 at 6:07 PM, Christoph M. Becker  wrote:
> On 29.06.2018 at 16:54, Andrey Andreev wrote:
>
>> On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev  
>> wrote:
>>>
 Readline is the only extension in your list that I would be sad about
 losing. I use it every day, I guess a lot of devs do.
>>>
>>> It's not "losing", per se, as the code doesn't get erased, it just moved
>>> to PECL. All distros can build it from there just as they do now. Then
>>> again, if it's super-important and doesn't have any major issues, we
>>> could keep it (or any other extension) around in "community maintained"
>>> status for a while.
>>
>> If "php -a" doesn't work without ext/readline (and I know it never
>> works for me if I don't install the distro-provided php-readline
>> package), then it is super-important.
>
> It's not about removing readline support for the interactive PHP shell,
> see .
>

I know it's not about that, but the problem is that currently (or on
7.0.x at least) the interactive shell doesn't work without the
extension.

Cheers,
Andrey.

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

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions YasuoOhgaki

[Christoph M. Becker]

On 29.06.2018 at 16:54, Andrey Andreev wrote:

> On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev  
> wrote:
>>
>>> Readline is the only extension in your list that I would be sad about
>>> losing. I use it every day, I guess a lot of devs do.
>>
>> It's not "losing", per se, as the code doesn't get erased, it just moved
>> to PECL. All distros can build it from there just as they do now. Then
>> again, if it's super-important and doesn't have any major issues, we
>> could keep it (or any other extension) around in "community maintained"
>> status for a while.
> 
> If "php -a" doesn't work without ext/readline (and I know it never
> works for me if I don't install the distro-provided php-readline
> package), then it is super-important.

It's not about removing readline support for the interactive PHP shell,
see .

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions Yasuo Ohgaki

[Andrey Andreev]

Hi,

On Fri, Jun 29, 2018 at 9:39 AM, Stanislav Malyshev  wrote:
> Hi!
>
>
>> Readline is the only extension in your list that I would be sad about
>> losing. I use it every day, I guess a lot of devs do.
>
> It's not "losing", per se, as the code doesn't get erased, it just moved
> to PECL. All distros can build it from there just as they do now. Then
> again, if it's super-important and doesn't have any major issues, we
> could keep it (or any other extension) around in "community maintained"
> status for a while.
>

If "php -a" doesn't work without ext/readline (and I know it never
works for me if I don't install the distro-provided php-readline
package), then it is super-important.

Cheers,
Andrey.

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

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions Yasuo Ohgaki

[Stanislav Malyshev]

Hi!


> Readline is the only extension in your list that I would be sad about
> losing. I use it every day, I guess a lot of devs do.

It's not "losing", per se, as the code doesn't get erased, it just moved
to PECL. All distros can build it from there just as they do now. Then
again, if it's super-important and doesn't have any major issues, we
could keep it (or any other extension) around in "community maintained"
status for a while.

-- 
Stas Malyshev
smalys...@gmail.com

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