Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator

[Larry Garfield]

On Fri, May 28, 2021, at 5:52 PM, Mel Dafert wrote:
> >It's ... checks calendar ... the year 2021. Do we *really* need to add a
> >procedural mirror APIs, especially with such auspicious function names as
> >datepatterngenerator_get_best_pattern?
> >
> >I believe the procedural APIs are considered legacy APIs, and we are
> >intentionally not adding them for new functionality. For example, the most
> >recent intl addition (IntlChar) does not come with procedural APIs.
> 
> I wasn't aware that there was a precedent with IntlChar - the 
> documentation seems
> to frame this duplication as a feature rather than a historical 
> artifact.
> (The wording "OO style vs procedural style" does not imply any 
> endorsement
> of one style over the other to me.)
> However, i am open to only including the OO API if there is consensus - 
> although
> I feel like this should maybe belong in a separate RFC that clarifies 
> that future
> additions should prefer the OO style, and
> that the OO style is the "preferred" one.

Agreed with Nikita.  There's no compelling reason to add double-API style 
anymore.  It may take a second RFC to modify this one to remove those, 
technically, but I'd vote for it.

--Larry Garfield

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

Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator

[Mel Dafert]

>It's ... checks calendar ... the year 2021. Do we *really* need to add a
>procedural mirror APIs, especially with such auspicious function names as
>datepatterngenerator_get_best_pattern?
>
>I believe the procedural APIs are considered legacy APIs, and we are
>intentionally not adding them for new functionality. For example, the most
>recent intl addition (IntlChar) does not come with procedural APIs.

I wasn't aware that there was a precedent with IntlChar - the documentation 
seems
to frame this duplication as a feature rather than a historical artifact.
(The wording "OO style vs procedural style" does not imply any endorsement
of one style over the other to me.)
However, i am open to only including the OO API if there is consensus - although
I feel like this should maybe belong in a separate RFC that clarifies that 
future
additions should prefer the OO style, and
that the OO style is the "preferred" one.

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

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

[Hendra Gunawan]

Hello.

>
> The only correct way to resolve this issue is to not support mutable 
> operations.
>

Correct me if I'm wrong: scalar object will hit memory limit earlier
than old API if it applied to $some_huge_shared_array for several
method calls.

>
> I don't think there's much need for mutable operations. sort() and shuffle() 
> would be best implemented by returning a new array instead. array_push() is 
> redundant with $array[]. array_shift() and array_unshift() should never be 
> used. array_pop() and array_splice() are the only sensible mutable array 
> methods that come to mind, and I daresay we can do without them.
>

Suppose that we all agree with that. **Will scalar object preserve
most of all functionality of the old API?** Some functions are very
handy that keep us away from the gory detail implementation. In array
case, we know that PHP array is a combination of array and plain
object in JS term. There is a trend in user land PHP library that they
are just copying the JS array API and poorly preserving the existing
functionality of PHP old API. Implicitly, the author of this thread
wants this to happen.

If I am not wrong, scalar object date back to before PHP 7.0. Is there
any consideration why scalar object was not escalated to the next
phase, say to RFC?

Regards
Hendra Gunawan.

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

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

[Mike Schinkel]

Hi Nikita,

Thank you for taking the time to explain in detail.  

One more question below.

-Mike

> On May 28, 2021, at 10:31 AM, Nikita Popov  wrote:
> 
> On Fri, May 28, 2021 at 3:11 AM Mike Schinkel  > wrote:
> > On May 26, 2021, at 7:44 PM, Hendra Gunawan  > > wrote:
> > 
> > Hello.
> > 
> >> 
> >> Yes, but Nikita wrote this note about technical limitations at the bottom 
> >> of the repo README:
> >> 
> >> Due to technical limitations, it is not possible to create mutable APIs for
> >> primitive types. Modifying $self within the methods is not possible (or
> >> rather, will have no effect, as you'd just be changing a copy).
> >> 
> > 
> > If it is solved, this is a great accomplishment for PHP. But I think
> > scalar object is not going anywhere in the near future. If you are not
> > convinced, please take a look
> > https://github.com/nikic/scalar_objects/issues/20#issuecomment-569520181 
> > .
> 
> Nikita's comment actually causes me more questions, not fewer.
> 
> Nikita says "We need to know that $a[$b][$c is an array in order to determine 
> that the call should be performed by-reference. However, we already need to 
> convert $a, $a[$b] and $a[$b][$c] into references before we know about that." 
>  
> 
> How then are we able to do the following?:
> 
> $a[$b][$c][] = 1;
> 
> In this case, we're clearly performing a write operation on the array. If you 
> want to know the technical details, the compiler will convert this into a 
> sequence of FETCH_DIM_W ops followed by ASSIGN_DIM. The "W" bit here is for 
> "write", which will perform all the necessary special handling, such as 
> copy-on-write separation and auto-vivification.
> 
> How also can we do this:
> 
> byref($a[$b][$c]);
> function byref(&$x) {
> $x[]= 2;
> }
> 
> See https://3v4l.org/aPvTD   >
> 
> This is a more complex case. In this case the compiler doesn't know in 
> advance whether the argument is passed by value or by reference. What happens 
> here is:
> 
> 1. INIT_FCALL determines that we're calling byref().
> 2. CHECK_FUNC_ARG for the first arg determines that this argument is passed 
> by-reference for this function.
> 3. FETCH_DIM_FUNC_ARG on the array will be perform either an FETCH_DIM_R or 
> to FETCH_DIM_W operation, depending on what CHECK_FUNC_ARG determined.
> 
> I assume that in both my examples $a[$b][$c] would be considered an 
> "lvalue"[1] and can be a target of assignment triggered by either the 
> assignment operator or calling the function and passing to a by-ref 
> parameter.  
> 
> [1] 
> https://en.wikipedia.org/wiki/Value_(computer_science)#Assignment:_l-values_and_r-values
>  
> 
> 
> So is there a reason that -> on an array could not trigger the same?  Is 
> Nikita saying that the performance of those calls performed by-reference 
> would not matter because they are always being assigned, at least in the 
> former case, but to do so with array expressions would be problematic? 
> (Ignoring there is no code in the wild that currently uses the -> operator, 
> or does that matter?)
> 
> Note that the byref($a[$b][$c]) case only works because we know which 
> function is being called at the time the argument is passed. If you have 
> $a[$b][$c]->test() we need to pass $a[$b][$c] by reference (FETCH_DIM_W) or 
> by value (FETCH_DIM_R) depending on whether $a[$b][$c]->test() accepts the 
> argument by-value or by-reference. But we can only know that once we have 
> already evaluated $a[$b][$c] and found out that it is indeed an array.
> 
> The only way around this is to *always* perform a for-write fetch of 
> $a[$b][$c], even though we don't know that the end result is going to be an 
> array. However, doing so would pessimize the performance of code operating on 
> objects. Consider $some_huge_shared_array[0]->foo(). If we fetch 
> $some_huge_shared_array for write, we'll be required to perform a full 
> duplication of the array in preparation for a possible future write. If it 
> turns out that $some_huge_shared_array[0] is actually an object, or that 
> $some_huge_shared_array[0] is an array and the performed operation is 
> by-value, then we have performed this copy unnecessarily.
> 
> I don't believe this is acceptable.
> 
> I ask honestly to understand, and not as a rhetorical question.
> 
> Additionally, if the case of updating an array variable is not a problem but 
> updating an array expression is a problem then why not just limit the -> 
> operator to only work on expressions for immutable methods and require 
> variables for mutable methods?  I would think should be easy enough to throw 
> an error for those specific "methods" that would be mutable, such as shift() 
> and unshift() if 

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

[Mark Randall]

On 28/05/2021 15:31, Nikita Popov wrote:

This is a more complex case. In this case the compiler doesn't know in
advance whether the argument is passed by value or by reference. What
happens here is:



I'm trying to wrap my head around this, but if a function arg can handle 
this, does something internal to the engine preclude fetching in write 
context, after already fetching in read context, other than performance?


So can the initial fetch be performed with FETCH_DIM_R, handling the 
object case + any other scalars, and if and only if the value is an 
array and operating on what would traditionally be a by-ref, repeating 
the previous lookup with FETCH_DIM_W?




Mark Randall

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

Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator

[Nikita Popov]

On Fri, May 14, 2021 at 5:56 PM Mel Dafert  wrote:

> Hi Internals,
> I have opened the vote on
> https://wiki.php.net/rfc/intldatetimepatterngenerator.
> I will close it on 2021-05-28.
>
> For previous discussion see https://externals.io/message/113831 and
> https://externals.io/message/114124.
>
> Regards,
> Mel
>

A bit late, but I have a small note on this RFC:

It's ... checks calendar ... the year 2021. Do we *really* need to add a
procedural mirror APIs, especially with such auspicious function names as
datepatterngenerator_get_best_pattern?

I believe the procedural APIs are considered legacy APIs, and we are
intentionally not adding them for new functionality. For example, the most
recent intl addition (IntlChar) does not come with procedural APIs.

Regards,
Nikita

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

[Nikita Popov]

On Fri, May 28, 2021 at 3:11 AM Mike Schinkel  wrote:

> > On May 26, 2021, at 7:44 PM, Hendra Gunawan 
> wrote:
> >
> > Hello.
> >
> >>
> >> Yes, but Nikita wrote this note about technical limitations at the
> bottom of the repo README:
> >>
> >> Due to technical limitations, it is not possible to create mutable APIs
> for
> >> primitive types. Modifying $self within the methods is not possible (or
> >> rather, will have no effect, as you'd just be changing a copy).
> >>
> >
> > If it is solved, this is a great accomplishment for PHP. But I think
> > scalar object is not going anywhere in the near future. If you are not
> > convinced, please take a look
> > https://github.com/nikic/scalar_objects/issues/20#issuecomment-569520181
> .
>
> Nikita's comment actually causes me more questions, not fewer.
>
> Nikita says "We need to know that $a[$b][$c is an array in order to
> determine that the call should be performed by-reference. However, we
> already need to convert $a, $a[$b] and $a[$b][$c] into references before we
> know about that."
>
> How then are we able to do the following?:
>
> $a[$b][$c][] = 1;
>

In this case, we're clearly performing a write operation on the array. If
you want to know the technical details, the compiler will convert this into
a sequence of FETCH_DIM_W ops followed by ASSIGN_DIM. The "W" bit here is
for "write", which will perform all the necessary special handling, such as
copy-on-write separation and auto-vivification.

How also can we do this:
>
> byref($a[$b][$c]);
> function byref(&$x) {
> $x[]= 2;
> }
>
> See https://3v4l.org/aPvTD 
>

This is a more complex case. In this case the compiler doesn't know in
advance whether the argument is passed by value or by reference. What
happens here is:

1. INIT_FCALL determines that we're calling byref().
2. CHECK_FUNC_ARG for the first arg determines that this argument is passed
by-reference for this function.
3. FETCH_DIM_FUNC_ARG on the array will be perform either an FETCH_DIM_R or
to FETCH_DIM_W operation, depending on what CHECK_FUNC_ARG determined.

I assume that in both my examples $a[$b][$c] would be considered an
> "lvalue"[1] and can be a target of assignment triggered by either the
> assignment operator or calling the function and passing to a by-ref
> parameter.
>
> [1]
> https://en.wikipedia.org/wiki/Value_(computer_science)#Assignment:_l-values_and_r-values
>
> So is there a reason that -> on an array could not trigger the same?  Is
> Nikita saying that the performance of those calls performed by-reference
> would not matter because they are always being assigned, at least in the
> former case, but to do so with array expressions would be problematic?
> (Ignoring there is no code in the wild that currently uses the -> operator,
> or does that matter?)
>

Note that the byref($a[$b][$c]) case only works because we know which
function is being called at the time the argument is passed. If you have
$a[$b][$c]->test() we need to pass $a[$b][$c] by reference (FETCH_DIM_W) or
by value (FETCH_DIM_R) depending on whether $a[$b][$c]->test() accepts the
argument by-value or by-reference. But we can only know that once we have
already evaluated $a[$b][$c] and found out that it is indeed an array.

The only way around this is to *always* perform a for-write fetch of
$a[$b][$c], even though we don't know that the end result is going to be an
array. However, doing so would pessimize the performance of code operating
on objects. Consider $some_huge_shared_array[0]->foo(). If we fetch
$some_huge_shared_array for write, we'll be required to perform a full
duplication of the array in preparation for a possible future write. If it
turns out that $some_huge_shared_array[0] is actually an object, or that
$some_huge_shared_array[0] is an array and the performed operation is
by-value, then we have performed this copy unnecessarily.

I don't believe this is acceptable.

I ask honestly to understand, and not as a rhetorical question.
>
> Additionally, if the case of updating an array variable is not a problem
> but updating an array expression is a problem then why not just limit the
> -> operator to only work on expressions for immutable methods and require
> variables for mutable methods?  I would think should be easy enough to
> throw an error for those specific "methods" that would be mutable, such as
> shift() and unshift() if $a[$b][$c]->shift('foo') were called?
>

There are externalities associated even with the simple $x->foo() case,
though they are less severe. They primarily involve reduced ability to
analyze code in opcache.

In either case, this limitation does not seem reasonable to me from a
language design perspective. If $a->push($b) works, then $a[$k]->push($b)
can reasonably be expected to work as well.


> Or maybe just completely limit using the -> operator on array variables.
> Don't work on any array expressions for consistency. There is already
> precedence in PHP for operators that work on 

Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator

[Mel Dafert]

Hi Internals,

I am pleased to announce that this RFC has been accepted unanimously.
I have closed the vote.

Regards,
Mel

- Original Message -
From: "Mel Dafert" 
To: "internals" 
Sent: Friday, May 14, 2021 5:56:23 PM
Subject: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator

Hi Internals,
I have opened the vote on https://wiki.php.net/rfc/intldatetimepatterngenerator.
I will close it on 2021-05-28.

For previous discussion see https://externals.io/message/113831 and 
https://externals.io/message/114124.

Regards,
Mel

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

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

Re: [PHP-DEV] Escape \0 in var_dump() output

[Nikita Popov]

On Thu, May 27, 2021 at 6:11 PM Sara Golemon  wrote:

> On Thu, May 27, 2021 at 9:07 AM Nikita Popov  wrote:
>
>> Ah, I think I explained the original issue badly: The test runner output
>> isn't really a problem, or at least I never perceived it to be.
>>
>> The problem is that if you change a test that contains a null byte
>> anywhere (read: in var_dump output), then github will not show a diff for
>> that file. You can see this nicely in the proposed PR itself:
>> https://github.com/php/php-src/pull/7059/files Most of the updated test
>> files show up as "Binary file not shown." As you can imagine, this makes
>> review hard. Using the .patch file doesn't help either, because it only
>> contains entries like:
>>
>>
> AH! Yeah, I completely misunderstood the problem space.  I didn't imagine
> for a second we had non-ASCII in any test because that's bad and it should
> feel bad.
>
> Okay, then I still disagree with changing var_dump()'s output, but for
> different reasons.
>
> So take Zend/tests/bug60569.phpt for example, which has this EXPECT
> section (where ^@ is actually the null byte):
>
> --EXPECT--
> string(20) "Some error ^@ message"
>
> Instead of changing how var_dump() works in order to produce different
> output, I'd change the EXPECT to and EXPECTF and add a new %0 pattern
>
> --EXPECTF--
> string(20) "Some error %0 message"
>
> This creates zero BC breaks, allows extensions to continue working just
> fine with raw nulls or update to use %0 if they'd like, and creates no
> ambiguities.
>

I like that approach. Implemented in
https://github.com/php/php-src/pull/7069.

Regards,
Nikita