Re: [PHP-DEV] Make sorting stable

[Andrea Faulds]

Christoph M. Becker wrote:

Given that we have internal classes which deliberately have such
comparison behavior (i.e. returning 0 or 1, to signal that there is no
order defined), e.g. Closures[1], I tend to prefer raising a warning
instead of trying to recover.


Oof… I wonder if we should make FALSE (maybe NULL too?) a special value 
to signify “no ordering”?


Thanks,
Andrea

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Rowan Tommins]

On 04/03/2020 20:01, Paul M. Jones wrote:

This RFC, in contrast, does not attempt to model HTTP messages. It does not 
attempt to discard previous ways of working. Instead, it proposes a more 
object-oriented representation of functionality that already exists in PHP, 
honoring that previously-existing approach. There is quite a bit of real-world 
experience as to how well it will work, since it takes into account many 
commonalities between existing userland projects. Thus, what the RFC purports 
to get close to is that existing way-of-working, and I think it succeeds about 
as well as can be possible for its goals.



This is something you have said a few times, and is definitely a worthy 
goal, but it's not something that comes across very strongly in the RFC 
itself. There is a comparison to Symfony HttpFoundation, but it mentions 
as many differences as similarities; and there is a list of 13 other 
implementations, but no information on how this proposal compares to them.


I suspect that's just because you didn't want to burden the RFC with too 
many details, but if you have any notes about what functionality is 
common in existing libraries, perhaps that could be posted somewhere as 
a kind of appendix to show where the current design came from?


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

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

Re: [PHP-DEV] Make sorting stable

[Christoph M. Becker]

On 04.03.2020 at 19:11, Nikita Popov wrote:

> 1. As Tyson suggests, we can throw a warning if a boolean is returned from
> the comparison callback (probably with a check to only throw it once per
> sort), to make it obvious what the cause is.
>
> 2. We can fix this transparently by doing something like this internally:
>
> $result = $compare($a, $b);
> if ($result !== false) {
> return (int) $result; // Normal behavior
> }
>
> // Bad comparison function, try the reverse order as well
> return -$compare($b, $a);
>
> That is, we will recover the full three-way comparison result from the
> "greater than" result, by checking for both $a > $b and $b > $a.

Given that we have internal classes which deliberately have such
comparison behavior (i.e. returning 0 or 1, to signal that there is no
order defined), e.g. Closures[1], I tend to prefer raising a warning
instead of trying to recover.

[1]


--
Christoph M. Becker

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

Re: [PHP-DEV] Make sorting stable

[Andrea Faulds]

Hi,

Larry Garfield wrote:

If I'm understanding the definition of stable here, it means that if two values 
evaluate to equal they will always end up in the same order in the output that 
they were in the input, yes?  So (trivial example):

$a = ["3", 2, 3, 5];

Sorts to:

[2, "3", 3, 5];

always, whereas right now it may sort to that or to [2, 3, "3", 5], somewhat 
randomly.  Am I understanding correctly?


(That is _my_ understanding, though I'd take Nikita's word for it rather 
than mine.)


I think you indirectly point out a good reason to have a stable sorting 
algorithm for PHP: PHP's weird type-juggling equality rules mean several 
kinds of values that are not really (===) equal will compare equal (==) 
so far as sorting cares, which probably means messy results sometimes 
when paired with an unstable sort?


Thanks,
Andrea

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

Re: [PHP-DEV] Re: Changing the generated name for anon classes

[Niklas Keller]

Hi Nikita,

while we're changing the naming scheme, could we also get rid of the
NUL byte, please? Binary in logs due to things like get_class really
isn't that nice.

Regarding checking whether something is an anonymous class, how about
adding a function to check whether a class name is an anonymous class?
Something like is_anonymous_class(get_class($obj));

Best,
Niklas

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

[PHP-DEV] Re: Make sorting stable

[Andrea Faulds]

Hi Nikita,

Nikita Popov wrote:

I believe that it is important for us to provide a stable sorting option in
the standard library. We could introduce a separate stable function(s) for
this purpose, but I believe we can just as well make all our existing sorts
stable.


I agree with having a stable sorting algorithm, because I suspect 
comparison functions in the wild are not exhaustive[0] enough to provide 
very stable orderings, so having a well-defined ordering is kinder to 
users — nobody wants sort() to scramble their array members if they 
compare equal, right?


[0] By “exhaustive” I mean checking _every_ part of each value, not just 
e.g. $a->name. Also, you might have SELECT'd some items from a database 
and the DB explicitly (ORDER BY) or implicitly ordered them, but you 
didn't think to include the thing ordered by in the SELECT'd columns.



The only issue I ran into is that this change has a negative impact on code
using illegal comparison callbacks like this:

usort($array, function($a, $b) {
 return $a > $b;
});

The return value of the sorting callback should be $a <=> $b, but using $a

$b also works right now, due to implementation details of the sorting

implementation (only the outcome of $compare($a, $b) > 0 ends up being used
by the sort).

This kind of incorrect code will break under the proposed implementation,
because we will now compare by original position if the comparison function
reports equality. Because the comparator reports equality inconsistently
(it says that $a == $b, but $b != $a), the sort results are also
inconsistent.


My personal feeling is stable sorting is more important than supporting 
broken callbacks, but I have no stats to base that on.


I think the suggestions in other emails of either trying to “fix” broken 
algorithms or to warn the user they're broken are good ideas. I might 
lean towards the latter given that:


• If such code was written before PHP 7.0 (IIRC) switched PHP to an 
unstable sort, the code would have been broken then and hopefully 
already fixed.
• PHP 7.0 introduced <=> to make writing correct comparison callbacks 
easier.
• We help the programmer to do the right thing by pointing it out to 
them, so they know what to do in future, and they get improved 
performance (I think?) for it.


Thanks,
Andrea

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

Re: [PHP-DEV] Make sorting stable

[Andreas Hennings]

Note that a comparison callback can also be broken in other ways:
- It could contain a loop, e.g. 'a' < 'b', 'b' < 'c', 'c' < 'a'.
- It could have alternating return values in subsequent calls with the same
arguments.

This kind of misbehavior cannot be easily detected.
The best we can do is make sure these kinds of comparison functions do not
cause infinite loops.

This said: Yes, stable sort out of the box would be a welcome feature.

On Wed, 4 Mar 2020 at 20:49, Larry Garfield  wrote:

> On Wed, Mar 4, 2020, at 12:35 PM, Sara Golemon wrote:
> > On Wed, Mar 4, 2020 at 12:12 PM Nikita Popov 
> wrote:
> >
> > > On Wed, Mar 4, 2020 at 6:17 PM Sara Golemon  wrote:
> > >
> > >> On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov 
> > >> wrote:
> > >>
> > >>> The only issue I ran into is that this change has a negative impact
> on
> > >>> code
> > >>> using illegal comparison callbacks like this:
> > >>>
> > >>> usort($array, function($a, $b) {
> > >>> return $a > $b;
> > >>> });
> > >>>
> > >>> Let's define what "negative impact" means in this regard.  Is it that
> > >> one still winds up with an essentially sorted array, but hitherto
> "stable
> > >> appering" output is now stable in a different way?  Or is the result
> > >> actually just NOT sorted in a way that a reasonable user would
> consider
> > >> correct (e.g. 5 sorted before "3")?
> > >>
> > >
> > > "Negative impact" is PR speak for "completely broken" ;) Yes, it could
> > > sort 5 before 3. The comparison function becomes completely
> ill-defined and
> > > you get Garbage-In-Garbage-Out.
> > >
> > > Roger that, thanks for explaining. 
> >
> >
> > > If we are concerned about this (I'm not sure we should be, but I've at
> > > least seen people be interested about this peculiar behavior:
> > >
> https://stackoverflow.com/questions/59908195/how-come-usort-php-works-even-when-not-returning-integers
> ),
> > > there's two things we can do:
> > >
> > > 1. As Tyson suggests, we can throw a warning if a boolean is returned
> from
> > > the comparison callback (probably with a check to only throw it once
> per
> > > sort), to make it obvious what the cause is.
> > >
> > > 2. We can fix this transparently by doing something like this
> internally:
> > >
> > > $result = $compare($a, $b);
> > > if ($result !== false) {
> > > return (int) $result; // Normal behavior
> > > }
> > >
> > > // Bad comparison function, try the reverse order as well
> > > return -$compare($b, $a);
> > >
> > >
> > ¿Por que no los dos?
> >
> > Fixing broken stuff transparently for a smooth upgrade path PLUS letting
> > people know they're doing it wrong seems win-win and low cost.
> >
> > -Sara
>
>
> I concur.  If a comparison function returns a non-legal value:
>
> 1) Fold it to a legal value. if feasible.
> 2) Raise a notice/warning, maybe deprecated? that tells them they're Doing
> It Wrong(tm)
> 3) Sometime in the future turn that notice/warning into a hard error.
>
> If I'm understanding the definition of stable here, it means that if two
> values evaluate to equal they will always end up in the same order in the
> output that they were in the input, yes?  So (trivial example):
>
> $a = ["3", 2, 3, 5];
>
> Sorts to:
>
> [2, "3", 3, 5];
>
> always, whereas right now it may sort to that or to [2, 3, "3", 5],
> somewhat randomly.  Am I understanding correctly?
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Paul M. Jones]

Hi Dan,

Thanks for taking the time to bring up your concerns. While I don't expect to 
change your mind (nice though that would be!) perhaps other readers here will 
find my counter-positions useful.


> On Mar 3, 2020, at 16:58, Dan Ackroyd  wrote:
> 
> Paul M. Jones  wrote:
> 
>> Are there any members here who currently expect to vote "no",
> 
> The only reason for doing this as C code appears to be make it have
> read-only properties.

Not the *only* reason, though it's true that it would be 
difficult-to-impossible to do outside of C. As Rowan mentioned earlier, and as 
I opined in an unpublished version of the RFC, one other reason would be to 
provide a language-level OO-ish representation of PHP functions, similar to 
what ext/mysqli and ext/date do.


> This is a hack

I dispute the word "hack" -- a readonly feature is requested here from time to 
time -- though I do understand that it is an uncommon approach.


> that would confuse a lot of developers


I think you're right that it might confuse some developers, but I also opine 
that just as many or more would "get it" either right away or very quickly.


> and instantly be added to most lists of "how PHP is bad".


Adding one point to the many thousands that already exist on such 
ill-considered lists, so not much of a change there. ;-)


> Tying this into core means that:
> 
> - BC breaking changes could only happen on major versions.
> 
> - Discussion of those changes would take up a lot of time, or more
> likely never happen. See all of our core extensions that are
> desperately in need of a maintainer to work on them.
> 
> - It might be impossible (or at least annoyingly difficult) to write
> code that was compatible with two versions of PHP, if they used this
> 
> ...
> 
> For stuff to be added to core, to overcome the burden of supporting in
> the future, there needs to be a strong reason to add it. Not just
> something that could be done.

All of your points are completely true. In fact, they are true for every RFC 
presented on this list; past, present, and future. So while you're correct, I 
have a hard time seeing it as a criticism specific to this proposal. (I'd be 
happy to see refinement of your points toward more specificity, if feel so 
inclined.)

Having said that, I'll present a past example that may tie it more specifically 
to this RFC. The Same Site Cookie proposal 
 hits around the points you mention: 
a change to long-standing behavior that might have entailed a BC break, 
discussion of that change, and code compatibility. All of those were managed 
quite successfully and in a reasonable timeframe. And although you voted 
against that proposal, it did pass, and has turned out to be pretty good; I 
imagine the same kind of change-success, if it is ever needed after adoption, 
is just as likely for this RFC as well.


> As you were involved and so know, a huge amount of energy was spent
> designing PSR-7, and still it was definitely not a perfect design. The
> chances of the design of this API being even as close as PSR-7 was,
> seems minimal.

I know you're not especially a fan of PSR-7 
 so arguing in 
its defense, against interest, is laudable. Good form!

But your phrasing about this RFC "being even as close as PSR-7 was" raises the 
question: "as close" to what?

The PSR-7 interfaces, and their many differing implementations, attempt to 
model HTTP messages as immutable objects. Indeed, the PSR-7 design process 
ended up discounting and discarding all pre-existing ways-of-working in PHP 
land, to the point of ignoring all previous implementations in the FIG member 
projects and elsewhere. Instead, PSR-7 declared "year zero" and presented an 
entirely new way of working that was completely different from and unrelated to 
anything else in PHP-land at that time. (For a brief history of the PSR-7 
design evolution, see the first few slides of my talk on PSR-7 and ADR at 
.) Among other things, that meant 
there was no applicable real-world experience as to how well PSR-7 would work 
in the mid-to-long term.

That historical context may make it easier to see why "a huge amount of energy 
was spent designing PSR-7", while resulting in something that was "definitely 
not a perfect design", in order to get close to a model of HTTP messages.

This RFC, in contrast, does not attempt to model HTTP messages. It does not 
attempt to discard previous ways of working. Instead, it proposes a more 
object-oriented representation of functionality that already exists in PHP, 
honoring that previously-existing approach. There is quite a bit of real-world 
experience as to how well it will work, since it takes into account many 
commonalities between existing userland projects. Thus, what the RFC purports 
to get close to is that existing way-of-working, and I think it succeeds about 
as well 

Re: [PHP-DEV] Make sorting stable

[Larry Garfield]

On Wed, Mar 4, 2020, at 12:35 PM, Sara Golemon wrote:
> On Wed, Mar 4, 2020 at 12:12 PM Nikita Popov  wrote:
> 
> > On Wed, Mar 4, 2020 at 6:17 PM Sara Golemon  wrote:
> >
> >> On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov 
> >> wrote:
> >>
> >>> The only issue I ran into is that this change has a negative impact on
> >>> code
> >>> using illegal comparison callbacks like this:
> >>>
> >>> usort($array, function($a, $b) {
> >>> return $a > $b;
> >>> });
> >>>
> >>> Let's define what "negative impact" means in this regard.  Is it that
> >> one still winds up with an essentially sorted array, but hitherto "stable
> >> appering" output is now stable in a different way?  Or is the result
> >> actually just NOT sorted in a way that a reasonable user would consider
> >> correct (e.g. 5 sorted before "3")?
> >>
> >
> > "Negative impact" is PR speak for "completely broken" ;) Yes, it could
> > sort 5 before 3. The comparison function becomes completely ill-defined and
> > you get Garbage-In-Garbage-Out.
> >
> > Roger that, thanks for explaining. 
> 
> 
> > If we are concerned about this (I'm not sure we should be, but I've at
> > least seen people be interested about this peculiar behavior:
> > https://stackoverflow.com/questions/59908195/how-come-usort-php-works-even-when-not-returning-integers),
> > there's two things we can do:
> >
> > 1. As Tyson suggests, we can throw a warning if a boolean is returned from
> > the comparison callback (probably with a check to only throw it once per
> > sort), to make it obvious what the cause is.
> >
> > 2. We can fix this transparently by doing something like this internally:
> >
> > $result = $compare($a, $b);
> > if ($result !== false) {
> > return (int) $result; // Normal behavior
> > }
> >
> > // Bad comparison function, try the reverse order as well
> > return -$compare($b, $a);
> >
> >
> ¿Por que no los dos?
> 
> Fixing broken stuff transparently for a smooth upgrade path PLUS letting
> people know they're doing it wrong seems win-win and low cost.
> 
> -Sara


I concur.  If a comparison function returns a non-legal value:

1) Fold it to a legal value. if feasible.
2) Raise a notice/warning, maybe deprecated? that tells them they're Doing It 
Wrong(tm)
3) Sometime in the future turn that notice/warning into a hard error.

If I'm understanding the definition of stable here, it means that if two values 
evaluate to equal they will always end up in the same order in the output that 
they were in the input, yes?  So (trivial example):

$a = ["3", 2, 3, 5];

Sorts to:

[2, "3", 3, 5];

always, whereas right now it may sort to that or to [2, 3, "3", 5], somewhat 
randomly.  Am I understanding correctly?

--Larry Garfield

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

Re: [PHP-DEV] Make sorting stable

[Sara Golemon]

On Wed, Mar 4, 2020 at 12:12 PM Nikita Popov  wrote:

> On Wed, Mar 4, 2020 at 6:17 PM Sara Golemon  wrote:
>
>> On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov 
>> wrote:
>>
>>> The only issue I ran into is that this change has a negative impact on
>>> code
>>> using illegal comparison callbacks like this:
>>>
>>> usort($array, function($a, $b) {
>>> return $a > $b;
>>> });
>>>
>>> Let's define what "negative impact" means in this regard.  Is it that
>> one still winds up with an essentially sorted array, but hitherto "stable
>> appering" output is now stable in a different way?  Or is the result
>> actually just NOT sorted in a way that a reasonable user would consider
>> correct (e.g. 5 sorted before "3")?
>>
>
> "Negative impact" is PR speak for "completely broken" ;) Yes, it could
> sort 5 before 3. The comparison function becomes completely ill-defined and
> you get Garbage-In-Garbage-Out.
>
> Roger that, thanks for explaining. 


> If we are concerned about this (I'm not sure we should be, but I've at
> least seen people be interested about this peculiar behavior:
> https://stackoverflow.com/questions/59908195/how-come-usort-php-works-even-when-not-returning-integers),
> there's two things we can do:
>
> 1. As Tyson suggests, we can throw a warning if a boolean is returned from
> the comparison callback (probably with a check to only throw it once per
> sort), to make it obvious what the cause is.
>
> 2. We can fix this transparently by doing something like this internally:
>
> $result = $compare($a, $b);
> if ($result !== false) {
> return (int) $result; // Normal behavior
> }
>
> // Bad comparison function, try the reverse order as well
> return -$compare($b, $a);
>
>
¿Por que no los dos?

Fixing broken stuff transparently for a smooth upgrade path PLUS letting
people know they're doing it wrong seems win-win and low cost.

-Sara

Re: [PHP-DEV] Make sorting stable

[Nikita Popov]

On Wed, Mar 4, 2020 at 6:17 PM Sara Golemon  wrote:

> On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov  wrote:
>
>> The only issue I ran into is that this change has a negative impact on
>> code
>> using illegal comparison callbacks like this:
>>
>> usort($array, function($a, $b) {
>> return $a > $b;
>> });
>>
>> Let's define what "negative impact" means in this regard.  Is it that one
> still winds up with an essentially sorted array, but hitherto "stable
> appering" output is now stable in a different way?  Or is the result
> actually just NOT sorted in a way that a reasonable user would consider
> correct (e.g. 5 sorted before "3")?
>

"Negative impact" is PR speak for "completely broken" ;) Yes, it could sort
5 before 3. The comparison function becomes completely ill-defined and you
get Garbage-In-Garbage-Out.

If we are concerned about this (I'm not sure we should be, but I've at
least seen people be interested about this peculiar behavior:
https://stackoverflow.com/questions/59908195/how-come-usort-php-works-even-when-not-returning-integers),
there's two things we can do:

1. As Tyson suggests, we can throw a warning if a boolean is returned from
the comparison callback (probably with a check to only throw it once per
sort), to make it obvious what the cause is.

2. We can fix this transparently by doing something like this internally:

$result = $compare($a, $b);
if ($result !== false) {
return (int) $result; // Normal behavior
}

// Bad comparison function, try the reverse order as well
return -$compare($b, $a);

That is, we will recover the full three-way comparison result from the
"greater than" result, by checking for both $a > $b and $b > $a.


> If it's the former, then I'm generally disinclined to be concerned about
> the breakage.  We never made a promise about comparison equality
> resolution, so moving to making a promise about it isn't violating anything.
>
>
>
>> This kind of incorrect code will break under the proposed implementation,
>> because we will now compare by original position if the comparison
>> function
>> reports equality. Because the comparator reports equality inconsistently
>> (it says that $a == $b, but $b != $a), the sort results are also
>> inconsistent.
>>
>> I read this user-space comparator as saying that values are never equal.
> Sometimes $a > $b and $b > $a are both true, which is terrible.  But if
> they never report equality, then position sorting should never come into
> play.
>

That's not what this comparator does: The result gets interpreted as the
usual -1/0/1 three-way comparison result, so "return $a > $b" will report
true == 1 == greater-than if $a is greater than $b (this is correct!) and
will report false == 0 == equals if $a equals $b (this is also correct) or
if $a is smaller than $b (this is wrong).

This ends up working, because the sort implementation happened to never
make a distinction between 0 and -1 return value. Now it does, and thus
results in an incorrect result.

Nikita

Re: [PHP-DEV] OSI approval for PHP 3.01 license

[Derick Rethans]

On Wed, 4 Mar 2020, Ben Ramsey wrote:

> > On Mar 4, 2020, at 11:26, Stanislav Malyshev  wrote:
> > 
> > Hi!
> > 
> >> Does anyone here remember why the changes to the license where done in
> >> the first place? The commit was done on the 1st of Jan. 2006 (at least
> > 
> > Probably for more clear wording (since outside of context "PHP" can mean
> > many things).
> > 
> > Since 3.0 and 3.01 are essentially the same license, I'm not sure who
> > would bother to go through the bureaucracy, not sure who did it the last
> > time (or whether anybody did that at all). Maybe worth reaching out to
> > OSI folks and asking them to update their list, since 3.0 and 3.01 are
> > the same.
> 
> I’m on the OSI license-discuss mailing list and happy to open up a 
> conversation there, unless there are objections?

Please do. I ran into this the other day when I was rewriting the README 
for Xdebug too: 
https://github.com/xdebug/xdebug/commit/c4371d9d18957965a590daee13bca82ff5205324#diff-88b99bb28683bd5b7e3a204826ead112R92-R96

cheers,
Derick

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] OSI approval for PHP 3.01 license

[Christoph M. Becker]

On 04.03.2020 at 18:51, Ben Ramsey wrote:

>> On Mar 4, 2020, at 11:26, Stanislav Malyshev  wrote:
>>
>>> Does anyone here remember why the changes to the license where done in
>>> the first place? The commit was done on the 1st of Jan. 2006 (at least
>>
>> Probably for more clear wording (since outside of context "PHP" can mean
>> many things).
>>
>> Since 3.0 and 3.01 are essentially the same license, I'm not sure who
>> would bother to go through the bureaucracy, not sure who did it the last
>> time (or whether anybody did that at all). Maybe worth reaching out to
>> OSI folks and asking them to update their list, since 3.0 and 3.01 are
>> the same.
>
> I’m on the OSI license-discuss mailing list and happy to open up a 
> conversation there, unless there are objections?

On the contrary – that would be very much appreciated!

Thanks,
Christoph

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

Re: [PHP-DEV] OSI approval for PHP 3.01 license

[Ben Ramsey]

> On Mar 4, 2020, at 11:26, Stanislav Malyshev  wrote:
> 
> Hi!
> 
>> Does anyone here remember why the changes to the license where done in
>> the first place? The commit was done on the 1st of Jan. 2006 (at least
> 
> Probably for more clear wording (since outside of context "PHP" can mean
> many things).
> 
> Since 3.0 and 3.01 are essentially the same license, I'm not sure who
> would bother to go through the bureaucracy, not sure who did it the last
> time (or whether anybody did that at all). Maybe worth reaching out to
> OSI folks and asking them to update their list, since 3.0 and 3.01 are
> the same.
> --
> Stas Malyshev
> smalys...@gmail.com


I’m on the OSI license-discuss mailing list and happy to open up a conversation 
there, unless there are objections?

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] Make sorting stable

[Nicolas Grekas]

Le mer. 4 mars 2020 à 18:30, tyson andre  a
écrit :

> > What do people think about this? Is there interest in making sorting
> > stable? Is it okay to break code using illegal comparison callbacks?
>
> I'd be interested in having a stable sort.
>

A new SORT_STABLE flag would be great!

Re: [PHP-DEV] Make sorting stable

[tyson andre]

> What do people think about this? Is there interest in making sorting
> stable? Is it okay to break code using illegal comparison callbacks?

I'd be interested in having a stable sort.
When migrating from php 5.6 to 7 a long time ago,
the fact that sorting was no longer stable was an inconvenience for reasoning 
about code
(such as sorting a list of elements to render),
and making it stable again would be a benefit for people reading php code
(e.g. JS implementations now guarantee it - 
https://v8.dev/features/stable-sort).
I used the same type of userland fallback you discussed.

For illegal comparison callbacks, it would be useful to emit a notice such as 
the following:
(Not sure if the following would be accurate for all edge cases)

"E_DEPRECATED: The callback for sort() should return an integer, but returned a 
boolean.
To guarantee a correct sort, implementations should return negative numbers
if an element is less than another element.
To preserve the incorrect sorting behavior, cast the returned result to an 
integer."

(and check if the error handler threw a Throwable)

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

Re: [PHP-DEV] Re: OSI approval for PHP 3.01 license

[Stanislav Malyshev]

Hi!

> Does anyone here remember why the changes to the license where done in
> the first place? The commit was done on the 1st of Jan. 2006 (at least

Probably for more clear wording (since outside of context "PHP" can mean
many things).

Since 3.0 and 3.01 are essentially the same license, I'm not sure who
would bother to go through the bureaucracy, not sure who did it the last
time (or whether anybody did that at all). Maybe worth reaching out to
OSI folks and asking them to update their list, since 3.0 and 3.01 are
the same.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Make sorting stable

[Sara Golemon]

On Wed, Mar 4, 2020 at 10:42 AM Nikita Popov  wrote:

> The only issue I ran into is that this change has a negative impact on code
> using illegal comparison callbacks like this:
>
> usort($array, function($a, $b) {
> return $a > $b;
> });
>
> Let's define what "negative impact" means in this regard.  Is it that one
still winds up with an essentially sorted array, but hitherto "stable
appering" output is now stable in a different way?  Or is the result
actually just NOT sorted in a way that a reasonable user would consider
correct (e.g. 5 sorted before "3")?

If it's the former, then I'm generally disinclined to be concerned about
the breakage.  We never made a promise about comparison equality
resolution, so moving to making a promise about it isn't violating anything.



> This kind of incorrect code will break under the proposed implementation,
> because we will now compare by original position if the comparison function
> reports equality. Because the comparator reports equality inconsistently
> (it says that $a == $b, but $b != $a), the sort results are also
> inconsistent.
>
> I read this user-space comparator as saying that values are never equal.
Sometimes $a > $b and $b > $a are both true, which is terrible.  But if
they never report equality, then position sorting should never come into
play.


> What do people think about this? Is there interest in making sorting
> stable? Is it okay to break code using illegal comparison callbacks?
>
> Generally +1, just curious about what breaks and how.

-Sara

[PHP-DEV] Make sorting stable

[Nikita Popov]

Hi internals,

Sorting function in PHP currently do not guarantee stability, which means
that the result order of elements that compare equal is not defined.

To achieve a stable sort, you need to do something like this (untested):

$arrayAndPos = [];
$pos = 0;
foreach ($array as $value) {
$arrayAndPos[] = [$value, $pos++];
}
usort($arrayAndPos, function($a, $b) use($compare) {
return $compare($a[0], $b[0]) ?: $a[1] <=> $b[1];
});
$array = [];
foreach ($arrayAndPos as $elem) {
$array[] = $elem[0];
}

This is both cumbersome and very inefficient. Those temporary arrays
significantly increase memory usage, and hurt performance of the sort.

I believe that it is important for us to provide a stable sorting option in
the standard library. We could introduce a separate stable function(s) for
this purpose, but I believe we can just as well make all our existing sorts
stable.

This does not require actually switching sorting algorithms to something
like Timsort. We can essentially do the same as the above PHP code, just
much more efficiently. Due to certain implementation details, we can do
this without memory usage increase, and with minimal performance impact.
I've put https://github.com/php/php-src/pull/5236 up as a prototype.

The only issue I ran into is that this change has a negative impact on code
using illegal comparison callbacks like this:

usort($array, function($a, $b) {
return $a > $b;
});

The return value of the sorting callback should be $a <=> $b, but using $a
> $b also works right now, due to implementation details of the sorting
implementation (only the outcome of $compare($a, $b) > 0 ends up being used
by the sort).

This kind of incorrect code will break under the proposed implementation,
because we will now compare by original position if the comparison function
reports equality. Because the comparator reports equality inconsistently
(it says that $a == $b, but $b != $a), the sort results are also
inconsistent.

What do people think about this? Is there interest in making sorting
stable? Is it okay to break code using illegal comparison callbacks?

Regards,
Nikita

Re: [PHP-DEV] Re: OSI approval for PHP 3.01 license

[Andreas Heigl]

Hey All.

Am 04.03.20 um 10:05 schrieb Christoph M. Becker:
> On 03.03.2020 at 23:13, Matthew Sheahan wrote:
> 
>> My team’s ability to use the phpdbg utility hinges on OSI approval of its 
>> license.  Language at https://www.php.net/license/ indicates that the PHP 
>> 3.01 license is OSI approved, but OSI disagrees; 
>> https://opensource.org/licenses/alphabetical shows approval only of the PHP 
>> 3.0 license.  (The fact that 3.0 and 3.01 are substantively identical is no 
>> use to us at all.)  OSI, for its part, indicates that per 
>> https://opensource.org/approval, only the “License Steward” of the PHP 3.01 
>> license has standing to request that it be reviewed, via OSI’s License 
>> Review mailing list.
>>
>>
>>
>> I would like to see the license review process there carried out as soon as 
>> possible, and might suggest that the apparent inaccuracy of the claim of OSI 
>> approval for 3.01 on php.net is a matter for concern.
>>
>>
>>
>> Publicly available information does not yield any insight into who the 
>> “License Steward” of the PHP 3.01 license might be, or how to contact any 
>> responsible party at the PHP Group.  If anyone can direct me appropriately 
>> or forward this message to someone who can, I would very much appreciate it. 
>>  Thanks!
>>

Does anyone here remember why the changes to the license where done in
the first place? The commit was done on the 1st of Jan. 2006 (at least
according to
https://github.com/php/php-src/commit/56567d31b331d3ab7814b36867579116eb14da86#diff-9879d6db96fd29134fc802214163b95a)
and I couldn't find that commit on svn.php.net any more to have more
information on it...

Insight would be highly appreciated ;-)

Cheers

Andreas



-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Re: OSI approval for PHP 3.01 license

[Christoph M. Becker]

On 03.03.2020 at 23:13, Matthew Sheahan wrote:

> My team’s ability to use the phpdbg utility hinges on OSI approval of its 
> license.  Language at https://www.php.net/license/ indicates that the PHP 
> 3.01 license is OSI approved, but OSI disagrees; 
> https://opensource.org/licenses/alphabetical shows approval only of the PHP 
> 3.0 license.  (The fact that 3.0 and 3.01 are substantively identical is no 
> use to us at all.)  OSI, for its part, indicates that per 
> https://opensource.org/approval, only the “License Steward” of the PHP 3.01 
> license has standing to request that it be reviewed, via OSI’s License Review 
> mailing list.
>
>
>
> I would like to see the license review process there carried out as soon as 
> possible, and might suggest that the apparent inaccuracy of the claim of OSI 
> approval for 3.01 on php.net is a matter for concern.
>
>
>
> Publicly available information does not yield any insight into who the 
> “License Steward” of the PHP 3.01 license might be, or how to contact any 
> responsible party at the PHP Group.  If anyone can direct me appropriately or 
> forward this message to someone who can, I would very much appreciate it.  
> Thanks!
>
>
>
>

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