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
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
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
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];
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
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
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
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
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
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
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 >
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
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
> 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
>
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!
> 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
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
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
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) {
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
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;
>
21 matches
Mail list logo
