Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
Hi Nikita, Very good list, thank you. The only one I am totally not sure about is image(filled)polygon $numpoints. There are really tons of codes out there using it. There is little to no gain to remove it but create a load of 1st level support requests to many packages and applications. A deprecation notice in this case, in a not so well configured php, will break the image display. I would rather make a documentation deprecation. Once we move to namespace and objects for this, it is simple to provide a clean alternative (addPoint(s), etc). Best, On Mon, Mar 22, 2021 at 4:25 PM Nikita Popov wrote: > > Hi internals, > > It's time for another deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_1 > > This is a collection of minor deprecations that various people have put > together over the last ~2 years. This RFC was formerly targeted at PHP 8.0, > but was delayed to PHP 8.1 to reduce the amount of changes necessary for > PHP 8.0 compatibility. > > As usual, each deprecation will be voted in isolation. > > As we're still early in the release cycle, it's still possible to add > additional deprecation candidates, given reasoning for the deprecation, as > well as available alternatives. > > Of course, if there are compelling technical reasons why something should > not be deprecated, we can move things into the "Removed from this proposal" > section, in which case it will serve as documentation why some > functionality should not deprecated. > > Regards, > Nikita -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.
En mar, 29 jun 2021 21:33:19 +0200 Michał Marcin Brzuchalski escribió > Hi Manuel, > I think a Markdown document including PHP code snippet with above examples > could cause issues while parsing. > I can imagine parsers don't expect end-of-snippet tag "```" being not an > end tag actually. > > Cheers, > Michał Marcin Brzuchalski Hi, Michal, You can escape backticks using a different number of backticks as a wrapper. Examples: 1. ``There is a literal backtick (`) here.`` We're using two backstick as wrapper of one backtick. 2. Using Rowan example: php $markdown=``` PHP has lots of ways to write strings: ``` $example = 'hello'; $example = "hello"; $example = <
Re: [PHP-DEV] [Vote] Partial Function Application
On Tue, Jun 29, 2021 at 12:05 PM Larry Garfield wrote: > > On Tue, Jun 29, 2021, at 1:00 PM, Larry Garfield wrote: > > On Tue, Jun 29, 2021, at 12:30 PM, Guilliam Xavier wrote: > > > (Extracted from the "Pipe Operator, take 2" thread) > > > > > > On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield > > > wrote: > > > > > > > On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote: > > > > > > > > > Would a slimmed down version have more support? How about removing the > > > > > variadic operator, and let the user manually add the lambda for those > > > > > cases? > > > > > > > > I talked with Joe about this, and the answer is no. Most of the > > > > complexity comes from the initial "this is a function call, oops no, > > > > it's a > > > > partial call so we switch to doing that instead", which ends up > > > > interacting > > > > with the engine in a lot of different places. > > > > > > > > > > Are you saying that the implementation complexity is mainly due to chosing > > > a syntax that looks like a function call? > > > If yes, is it also the case for the "First-class callable syntax" RFC? > > > And does it mean that a different syntax (e.g. with a prefix operator) > > > would result in a simpler implementation? > > > > From what I understand from Joe, most of the complexity comes from > > producing something that isn't a closure but shares the same interface > > as a closure (at least that's what it would be in PHP terms), which > > then requires lots of special handling throughout the engine. I don't > > fully understand it all myself, TBH. > > > > I've been pondering if a completely different approach with a prefix > > symbol would be able to be less complex, and the simple answer is I > > have absolutely no idea. But we are running low on symbols... > > Ah, I found the technical details that Joe gave me (right after I hit send, > of course). Quoting Joe: > > "the engine expects certain things to happen, and is designed and then > optimized around those assumptions ... for example, a stream of INIT, SEND, > DO_FCALL is not meant to be interrupted, the first fundamental change you > have to make is making the engine aware that stream of INIT, SEND, + are not > always followed by DO_FCALL " > > So yes, it sounds like hooking into the function call process is where the > complexity comes from. Which suggests that an approach that works using a > different syntax that desugars to a closure would avoid that issue, but then > we need a syntax that wouldn't be ambiguous, and that's getting harder and > harder to find. (Nikita's first-class-callables RFC notes some of the issues > with available symbols, and they're essentially the same for partials either > way.) And I've been told that creating closures in the AST compiler is > Hard(tm)... > > --Larry Garfield Based on what you said, the syntax isn't really the issue. Rather, the issue is assumptions about how function calls work at the opcode level. Any implementation of only _partially_ doing a function call will have to deal with such things in some form. To a degree this is inherent complexity. Maybe separate opcodes for every piece of the call would be better in that optimizers, etc, won't have expectations around the new opcodes and we don't change assumptions about the existing opcodes? I doubt that it would be much simpler, but I am curious to know. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.
Hi Manuel, wt., 29 cze 2021 o 18:16 Manuel Canga napisał(a): > Hi, folks, here again with a new purpose: ``` as alternative to Nowdoc > syntax. > > Currently, Nowdoc syntax is very "verbose": > > $string =<<<'CODE' > > Link: '%s' > > CODE; > > Why doesn't something like this?: > > $string =``` > > Link: '%s' > > ```; > > even as well: > > $string =```Link: '%s'```; > > > I see a caveat: this is very similar to `eval` syntax. However, this > syntax is more similar to Markdown syntax. > > What do you think ? > I think a Markdown document including PHP code snippet with above examples could cause issues while parsing. I can imagine parsers don't expect end-of-snippet tag "```" being not an end tag actually. Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [Vote] Partial Function Application
On Tue, Jun 29, 2021, at 1:00 PM, Larry Garfield wrote: > On Tue, Jun 29, 2021, at 12:30 PM, Guilliam Xavier wrote: > > (Extracted from the "Pipe Operator, take 2" thread) > > > > On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield > > wrote: > > > > > On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote: > > > > > > > Would a slimmed down version have more support? How about removing the > > > > variadic operator, and let the user manually add the lambda for those > > > > cases? > > > > > > I talked with Joe about this, and the answer is no. Most of the > > > complexity comes from the initial "this is a function call, oops no, it's > > > a > > > partial call so we switch to doing that instead", which ends up > > > interacting > > > with the engine in a lot of different places. > > > > > > > Are you saying that the implementation complexity is mainly due to chosing > > a syntax that looks like a function call? > > If yes, is it also the case for the "First-class callable syntax" RFC? > > And does it mean that a different syntax (e.g. with a prefix operator) > > would result in a simpler implementation? > > From what I understand from Joe, most of the complexity comes from > producing something that isn't a closure but shares the same interface > as a closure (at least that's what it would be in PHP terms), which > then requires lots of special handling throughout the engine. I don't > fully understand it all myself, TBH. > > I've been pondering if a completely different approach with a prefix > symbol would be able to be less complex, and the simple answer is I > have absolutely no idea. But we are running low on symbols... Ah, I found the technical details that Joe gave me (right after I hit send, of course). Quoting Joe: "the engine expects certain things to happen, and is designed and then optimized around those assumptions ... for example, a stream of INIT, SEND, DO_FCALL is not meant to be interrupted, the first fundamental change you have to make is making the engine aware that stream of INIT, SEND, + are not always followed by DO_FCALL " So yes, it sounds like hooking into the function call process is where the complexity comes from. Which suggests that an approach that works using a different syntax that desugars to a closure would avoid that issue, but then we need a syntax that wouldn't be ambiguous, and that's getting harder and harder to find. (Nikita's first-class-callables RFC notes some of the issues with available symbols, and they're essentially the same for partials either way.) And I've been told that creating closures in the AST compiler is Hard(tm)... --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Vote] Partial Function Application
On Tue, Jun 29, 2021, at 12:30 PM, Guilliam Xavier wrote: > (Extracted from the "Pipe Operator, take 2" thread) > > On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield > wrote: > > > On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote: > > > > > Would a slimmed down version have more support? How about removing the > > > variadic operator, and let the user manually add the lambda for those > > > cases? > > > > I talked with Joe about this, and the answer is no. Most of the > > complexity comes from the initial "this is a function call, oops no, it's a > > partial call so we switch to doing that instead", which ends up interacting > > with the engine in a lot of different places. > > > > Are you saying that the implementation complexity is mainly due to chosing > a syntax that looks like a function call? > If yes, is it also the case for the "First-class callable syntax" RFC? > And does it mean that a different syntax (e.g. with a prefix operator) > would result in a simpler implementation? >From what I understand from Joe, most of the complexity comes from producing >something that isn't a closure but shares the same interface as a closure (at >least that's what it would be in PHP terms), which then requires lots of >special handling throughout the engine. I don't fully understand it all >myself, TBH. I've been pondering if a completely different approach with a prefix symbol would be able to be less complex, and the simple answer is I have absolutely no idea. But we are running low on symbols... --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Vote] Partial Function Application
On Tue, Jun 29, 2021 at 11:04 AM Côme Chilliet < come.chill...@fusiondirectory.org> wrote: > Le Thu, 17 Jun 2021 08:30:43 -0500, > "Larry Garfield" a écrit : > > > > The ? character was chosen for the placeholder largely because it was > > > > unambiguous and easy to implement. Prior, similar RFCs (such as the > > > > original Pipe Operator proposal from several years ago) used the $$ > > > > (lovingly called T_BLING) sigil instead. So far no compelling > argument > > > > has been provided for changing the character, so the RFC is sticking > > > > with ?. > > > > > > The main argument for $$ is to be able to have partial methods with > $$->, > > > this should be stated in this paragraph. > > > > That's not something that was ever brought up in the discussion. > > Finally found where I read that, it’s in an other RFC: > > https://wiki.php.net/rfc/first_class_callable_syntax#partial_function_application > For the record, Larry replied on this subject: https://externals.io/message/114770#114785 (second part). Note that for `$$->foo(/*whatever*/)` the signature couldn't be extracted (because the class of $$ is unknown). Regards, -- Guilliam Xavier
Re: [PHP-DEV] [Vote] Partial Function Application
(Extracted from the "Pipe Operator, take 2" thread) On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield wrote: > On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote: > > > Would a slimmed down version have more support? How about removing the > > variadic operator, and let the user manually add the lambda for those > > cases? > > I talked with Joe about this, and the answer is no. Most of the > complexity comes from the initial "this is a function call, oops no, it's a > partial call so we switch to doing that instead", which ends up interacting > with the engine in a lot of different places. > Are you saying that the implementation complexity is mainly due to chosing a syntax that looks like a function call? If yes, is it also the case for the "First-class callable syntax" RFC? And does it mean that a different syntax (e.g. with a prefix operator) would result in a simpler implementation? Regards, -- Guilliam Xavier
Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.
En mar, 29 jun 2021 18:40:05 +0200 Rowan Tommins escribió > > The big advantage of heredoc and nowdoc syntax is that you can choose > the delimiter to be something that you know won't occur in the string. > For instance: > > $markdown = <<<'MD' > PHP has lots of ways to write strings: > ``` > $example = 'hello'; > $example = "hello"; > $example = << hello > EXAMPLE; > $example = << hello > EXAMPLE; > ``` > MD; > > > Unless I'm missing something, your proposed syntax would just be a *more > verbose* way of writing single quotes. Hi, Rowan, Basically, you're right. This would be a Heredoc variant of writing text without worrying about quotes (singles or doubles). Something like: $quote =```"Sometimes it's better to leave something alone, to pause, and that's very true of programming." - Joyce Wheeler```; Regards Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.
On 29/06/2021 17:15, Manuel Canga wrote: Hi, folks, here again with a new purpose: ``` as alternative to Nowdoc syntax. Currently, Nowdoc syntax is very "verbose": $string =<<<'CODE' Link: '%s' CODE; The big advantage of heredoc and nowdoc syntax is that you can choose the delimiter to be something that you know won't occur in the string. For instance: $markdown = <<<'MD' PHP has lots of ways to write strings: ``` $example = 'hello'; $example = "hello"; $example = <
[PHP-DEV] [RFC] Alternative syntax for Nowdoc.
Hi, folks, here again with a new purpose: ``` as alternative to Nowdoc syntax. Currently, Nowdoc syntax is very "verbose": $string =<<<'CODE' Link: '%s' CODE; Why doesn't something like this?: $string =``` Link: '%s' ```; even as well: $string =```Link: '%s'```; I see a caveat: this is very similar to `eval` syntax. However, this syntax is more similar to Markdown syntax. What do you think ? Regards Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str
On Thu, Jun 24, 2021 at 1:20 AM Sara Golemon wrote:
> On Wed, Jun 23, 2021 at 5:02 PM Kamil Tekiela
> wrote:
>
> > I would like to propose a new simple RFC that aims to add a new function
> > called parse_query_string as an alternative to parse_str.
> >
> > https://wiki.php.net/rfc/parse_str_alternative
> >
> > The functionality stays the same, only the name and the way of returning
> > the array changes. While it is a rather insignificant change, I believe
> it
> > is one step closer to making PHP cleaner.
> >
> >
> There's a potential alternative option that doesn't require adding a new,
> parallel function. We can use execute_data->return_value_used to figure
> out if parse_str() was called with the result assigned to a local var.
> This is overloady and probably a bad idea, but it's an option.
>
> if (ZEND_NUM_ARGS() == 2) {
> // Put result into by-ref second arg
> // parse_str($str, $refResult);
> } else if (EX(return_value_used)) {
> // Put result into return_value
> // $result = parse_str($str);
> } else {
> // Put result into EG(local_symbol_table)
> // parse_str($str);
> php_error(E_DEPRECATED, ...);
> }
return_value_used is a hint that cannot always be reliably determined. E.g.
if you go through something like call_user_func(), I believe it'll always
be set. I think if the observer infrastructure is used, it will also always
be set.
Using it is okay for optimization, but I don't think we should use this
flag to influence behavior.
Regards,
Nikita
Re: [PHP-DEV] [RFC] Add Random Extension (before: Add Random class)
On Sat, Jun 26, 2021 at 2:40 AM Go Kudo wrote: > Hello Internals. > > RFC has been reorganized for finalization. > > https://wiki.php.net/rfc/rng_extension > > The changes from the previous version are as follows: > > - Changed again to a class-based approach. The argument can be omitted, in > which case an instance of XorShift128Plus will be created automatically. > - Future scope was specified in the RFC and the functionality was separated > as a Random extension. > - Changed to separate it as a Random extension and use the appropriate > namespace. > - In order to extend the versatility of the final class, Random, a > RandomInterface has been added, similar in approach to the > DateTimeInterface. > The updated proposal looks quite nice :) I think this is close to done. Some small bits of feedback: * The first bit is just clarification. After a cursory look at the implementation, my understanding is that the getInt(), shuffleArray() and shuffleString() APIs will always produce consistent results on 32-bit and 64-bit, as long as your inputs are 32-bit as well (i.e., min/max are 32-bit and string is smaller than 4G). Is that correct? The only APIs that would exhibit different behavior are nextInt() and getBytes(), right? * Looking at the implementation, nextInt() performs a >> 1 operation on the RNG result. I assume the motivation is to get back a non-negative number. But why do we want that? The "nextInt()" name doesn't really indicate that it's a positive number. I think more generally, my question here may be "Why does this method exist at all? When would you use it instead of getInt()?" * Another bit of clarification: For the user-defined RNG, which range is generate() expected to return? I assume that it must return the native integer size, i.e. 32-bit on 32-bit and 64-bit on 64-bit? * I don't really get why we need RandomInterface. I think if the choice is between "final + interface" and "non-final without interface", I'd prefer the latter (though I'm also happy with "final without interface"). * I'm not entirely happy with the naming. Unfortunately, I don't have great suggestions either. I think in your current hierarchy, I would make the interface Random\NumberGenerator (with implementation in the sub-namespace), rather than Random\NumberGenerator\RandomNumberGenerator. Regards, Nikita I've done a tidy implementation to make this final, but I'm currently > suffering from error detection by Valgrind for unknown reasons. > > Implementation is here: https://github.com/php/php-src/pull/7079 > > This can be reproduced with the following code. > > ```sh > # Success > $ valgrind ./sapi/cli/php -r '$random = new Random(); $random->nextInt();' > ==95522== Memcheck, a memory error detector > ==95522== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==95522== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright > info > ==95522== Command: ./sapi/cli/php -r $random\ =\ new\ Random();\ > $random-\>nextInt(); > ==95522== > ==95522== > ==95522== HEAP SUMMARY: > ==95522== in use at exit: 1,286 bytes in 32 blocks > ==95522== total heap usage: 28,445 allocs, 28,413 frees, 4,333,047 bytes > allocated > ==95522== > ==95522== LEAK SUMMARY: > ==95522==definitely lost: 0 bytes in 0 blocks > ==95522==indirectly lost: 0 bytes in 0 blocks > ==95522== possibly lost: 0 bytes in 0 blocks > ==95522==still reachable: 1,286 bytes in 32 blocks > ==95522== suppressed: 0 bytes in 0 blocks > ==95522== Rerun with --leak-check=full to see details of leaked memory > ==95522== > ==95522== For counts of detected and suppressed errors, rerun with: -v > ==95522== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > # Fail > $ valgrind ./sapi/cli/php -r '$random = new Random(); $random->nextInt() > === $random->nextInt();' > ==95395== Memcheck, a memory error detector > ==95395== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==95395== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright > info > ==95395== Command: ./sapi/cli/php -r $random\ =\ new\ Random();\ > $random-\>nextInt()\ ===\ $random-\>nextInt(); > ==95395== > ==95395== Conditional jump or move depends on uninitialised value(s) > ==95395==at 0x966925: ZEND_IS_IDENTICAL_SPEC_VAR_VAR_HANDLER > (zend_vm_execute.h:27024) > ==95395==by 0x99AC27: execute_ex (zend_vm_execute.h:57236) > ==95395==by 0x99C902: zend_execute (zend_vm_execute.h:59026) > ==95395==by 0x8DB6B4: zend_eval_stringl (zend_execute_API.c:1191) > ==95395==by 0x8DB861: zend_eval_stringl_ex (zend_execute_API.c:1233) > ==95395==by 0x8DB8D6: zend_eval_string_ex (zend_execute_API.c:1243) > ==95395==by 0xA4DAE4: do_cli (php_cli.c:995) > ==95395==by 0xA4E8E2: main (php_cli.c:1366) > ==95395== > ==95395== > ==95395== HEAP SUMMARY: > ==95395== in use at exit: 1,286 bytes in 32 blocks > ==95395== total heap usage: 28,445 allocs, 28,413 frees, 4,333,070 bytes > allocated > ==95395==
Re: [PHP-DEV] Re: [RFC] Readonly properties
On Tue, Jun 29, 2021, at 8:08 AM, Nikita Popov wrote:
> > You might not like the boilerplate, but that just works.
> >
> > Can this be considered Nikita?
> >
>
> Well, it's a nifty hack :) I don't think this is the solution we want to
> encourage though. It requires you pass extra information through a
> side-channel -- I think I'd rather not use readonly than write that code.
>
> Continuing along the same line, one could extend that to "clone with
> argument" and do something like this:
>
> public function __clone(self $original, array $replacements = []) {
> foreach ($original as $k => $v) {
> $this->$k = $replacements[$k] ?? $original->$k;
> }
> }
>
> and then do "clone $this(['bar' => $bar])".
>
> In any case, I don't want to include changes to cloning in this proposal --
> the topic is related, but also orthogonal to readonly properties.
> Unfortunately, it will not be possible to get cloning changes into PHP 8.1
> anymore, due to feature freeze.
>
> It's okay to vote against this if cloning is a deal breaker. In that case
> I'll probably either work on cloning before re-proposing this, or pivot to
> asymmetric visibility -- it's not my first preference, but it may be the
> more pragmatic choice. Cloning is definitely the weak point of this
> proposal.
>
> Regards,
> Nikita
I already went through the clone-arguments mental exercise in my earlier
analysis, and the code it produces is totally disgusting. :-) clone-with is a
considerably better approach if you're starting from readonly. (It's also
better if you start from asymmetric visibility, although that version needs a
clone-help feature far less.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Readonly properties
Le 29/06/2021 à 15:08, Nikita Popov a écrit :
Well, it's a nifty hack :) I don't think this is the solution we want to
encourage though. It requires you pass extra information through a
side-channel -- I think I'd rather not use readonly than write that code.
Continuing along the same line, one could extend that to "clone with
argument" and do something like this:
public function __clone(self $original, array $replacements = []) {
foreach ($original as $k => $v) {
$this->$k = $replacements[$k] ?? $original->$k;
}
}
and then do "clone $this(['bar' => $bar])".
In any case, I don't want to include changes to cloning in this proposal --
the topic is related, but also orthogonal to readonly properties.
Unfortunately, it will not be possible to get cloning changes into PHP 8.1
anymore, due to feature freeze.
It's okay to vote against this if cloning is a deal breaker. In that case
I'll probably either work on cloning before re-proposing this, or pivot to
asymmetric visibility -- it's not my first preference, but it may be the
more pragmatic choice. Cloning is definitely the weak point of this
proposal.
Regards,
Nikita
Hello,
I agree that the "clone with" feature, no matter how the syntax will end
up being, will become vital as soon as readonly properties will be there
for many people.
Nevertheless, I also agree with you, both can be done at different
times, and even if it will block _some_ usages of readonly properties,
readonly properties as you propose remain a must-have (in my opinion)
even without the "clone with". I'd be pleased to use them an write
really immutable objects, even if for cloning I need to do new
Foo($otherFoo->prop1, $otherFoo->prop2), that's still a huge win in my
opinion.
I can't vote, but I can't say nothing if people want to block this RFC
for having the clone with at the same, whereas it could be in a RFC of
its own, and readonly properties are still a huge feature on its own,
even without "clone with" support. That's a very wrong reason to say no
in my opinion: on the contrary, having readonly properties being
accepted and implemented as-is will be a very persuasive argument in
favor of the future "clone with" RFC that may emerge following this one.
--
Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] First-class callable syntax
On Tue, Jun 29, 2021 at 10:36 AM Nikita Popov wrote:
> On Thu, May 20, 2021 at 2:48 PM Nikita Popov wrote:
>
>> Hi internals,
>>
>> I'd like to present an RFC for a first-class callable syntax, which is
>> intended as a simpler alternative to the partial function application (PFA)
>> proposal:
>>
>> https://wiki.php.net/rfc/first_class_callable_syntax
>>
>> See the Rationale section for details on how this relates to PFA. Over
>> the past week, we've had a lot of discussions on how exactly PFA is
>> supposed to work (most of them OTR), and while we seem to have a tentative
>> consensus on the correct model to use (which does not match the current
>> RFC), it's clear that this feature has turned out more complicated than
>> originally anticipated. Joe (who provided the implementation for the PFA
>> RFC) is also concerned about the implementation complexity that the final
>> model would require.
>>
>> At least I personally was mainly interested in PFA because it provides a
>> first-class callable syntax as a side-effect. This RFC goes back to
>> providing *just* that. The syntax is forward-compatible with a future PFA
>> proposal though.
>>
>> Regards,
>> Nikita
>>
>
> I've updated the RFC to forbid combination with the nullsafe operator, as
> well as explicitly mention strict types behavior, as these came up in the
> PFA discussion.
>
> I plan to put up this RFC for voting in the event that the PFA proposal
> does not get accepted.
>
As syntax has been the primary point of contention for this RFC, I've
considered adding a secondary vote for an alternative syntax, with the
prime contender being strlen::fn / $foo->bar::fn / Foo::bar::fn. I have
ultimately decided against this, because the ::fn syntax is not just a
minor syntax variation: It will result in materially different semantics.
While the end goal is the same, ::fn would approach it from a technically
quite different direction, by not piggy-backing on call syntax.
If this doesn't get accepted ("I like the idea but hate the syntax" is a
sensible reason to vote against), then I'd create a separate proposal for a
different syntax choice.
Regards,
Nikita
Re: [PHP-DEV] Re: [RFC] Readonly properties
On Tue, Jun 29, 2021 at 9:14 AM Nicolas Grekas
wrote:
> Le lun. 28 juin 2021 à 18:22, Larry Garfield a
>>> écrit :
>>>
On Mon, Jun 28, 2021, at 11:17 AM, Nicolas Grekas wrote:
> > > I'd like to open the discussion on readonly properties:
> > > https://wiki.php.net/rfc/readonly_properties_v2
> > >
> > > This proposal is similar to the
> > > https://wiki.php.net/rfc/write_once_properties RFC that has been
> > declined
> > > previously. One significant difference is that the new RFC limits
the
> > scope
> > > of initializing assignments. I think a key mistake of the
previous RFC
> > was
> > > the confusing "write-once" framing, which is both technically
correct and
> > > quite irrelevant.
> > >
> > > Please see the rationale section (
> > > https://wiki.php.net/rfc/readonly_properties_v2#rationale) for
how this
> > > proposal relates to other RFCs and alternatives.
> > >
> >
> > I plan to open voting on this RFC soon. I don't think there's
anything
> > technical left to address here, the discussion mostly comes down to
a value
> > judgement. I think everyone has made their position regarding that
clear...
> >
>
> Actually, we talked off the list about a way to possibly make this
work
> with __clone():
>
> We could allow __clone to have one argument, the object being cloned.
And
> when the signature declares this argument, then all readonly
properties
> would be set as uninitialized on $this.
>
> A typical __clone function would look like this with readonly
properties:
> function __clone(object $original)
> {
> $this->readonlyProp = clone $original->readonlyProp;
> }
>
> That would turn my vote into a +1 if that could be made to work!
That sounds like it would support deep cloning, but not with-er
methods. There's no way to provide a changed value. It also would mean a
lot of work on larger objects to transfer across all the properties. I
don't really see what this would add.
>>>
>>> Can you elaborate about the lack of support for withers? Having some
>>> work to do doesn't look like an issue to me, especially when there is no
>>> alternative to compare that too.
>>>
>>
>> I sent that too fast, I agree about withers... :)
>> I'm looking for a way to +1 that RFC...
>> Any other idea?
>>
>
> And I was too fast agreeing that my proposal to pass the original object
> as argument was incompatible with withers.
>
> I also think that not being compatible with deep cloning is a major issue.
> Past trivial cases, the use cases I can think of where I would use readonly
> require deep cloning. See eg the Symfony Request object where query params,
> headers, and a few others expose state as public objects.
>
> Here is some code that just works with them:
> class C
> {
> public readonly string $foo;
> public readonly string $bar;
>
> private $skipWhenCloning;
>
> public function withFoo($foo)
> {
> $this->skipWhenCloning = 'foo';
> $clone = clone $this;
> $clone->foo = $foo;
> }
>
> public function withBar($bar)
> {
> $this->skipWhenCloning = 'bar';
> $clone = clone $this;
> $clone->bar = $bar;
> }
>
> public function __clone(self $original)
> {
> foreach ($this as $k => $v) {
> if ($k !== $this->skipWhenCloning) {
> $this->$k = $original->$k;
> }
> }
> $this->skipWhenCloning = $original->skipWhenCloning = null;
> }
> }
>
> You might not like the boilerplate, but that just works.
>
> Can this be considered Nikita?
>
Well, it's a nifty hack :) I don't think this is the solution we want to
encourage though. It requires you pass extra information through a
side-channel -- I think I'd rather not use readonly than write that code.
Continuing along the same line, one could extend that to "clone with
argument" and do something like this:
public function __clone(self $original, array $replacements = []) {
foreach ($original as $k => $v) {
$this->$k = $replacements[$k] ?? $original->$k;
}
}
and then do "clone $this(['bar' => $bar])".
In any case, I don't want to include changes to cloning in this proposal --
the topic is related, but also orthogonal to readonly properties.
Unfortunately, it will not be possible to get cloning changes into PHP 8.1
anymore, due to feature freeze.
It's okay to vote against this if cloning is a deal breaker. In that case
I'll probably either work on cloning before re-proposing this, or pivot to
asymmetric visibility -- it's not my first preference, but it may be the
more pragmatic choice. Cloning is definitely the weak point of this
proposal.
Regards,
Nikita
Re: [PHP-DEV] [Vote] Partial Function Application
Le Thu, 17 Jun 2021 08:30:43 -0500, "Larry Garfield" a écrit : > > > The ? character was chosen for the placeholder largely because it was > > > unambiguous and easy to implement. Prior, similar RFCs (such as the > > > original Pipe Operator proposal from several years ago) used the $$ > > > (lovingly called T_BLING) sigil instead. So far no compelling argument > > > has been provided for changing the character, so the RFC is sticking > > > with ?. > > > > The main argument for $$ is to be able to have partial methods with $$->, > > this should be stated in this paragraph. > > That's not something that was ever brought up in the discussion. Finally found where I read that, it’s in an other RFC: https://wiki.php.net/rfc/first_class_callable_syntax#partial_function_application Côme -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] First-class callable syntax
2021-05-20 14:48 GMT+02:00, Nikita Popov :
> Hi internals,
>
> I'd like to present an RFC for a first-class callable syntax, which is
> intended as a simpler alternative to the partial function application (PFA)
> proposal:
>
> https://wiki.php.net/rfc/first_class_callable_syntax
>
> See the Rationale section for details on how this relates to PFA. Over the
> past week, we've had a lot of discussions on how exactly PFA is supposed to
> work (most of them OTR), and while we seem to have a tentative consensus on
> the correct model to use (which does not match the current RFC), it's clear
> that this feature has turned out more complicated than originally
> anticipated. Joe (who provided the implementation for the PFA RFC) is also
> concerned about the implementation complexity that the final model would
> require.
>
> At least I personally was mainly interested in PFA because it provides a
> first-class callable syntax as a side-effect. This RFC goes back to
> providing *just* that. The syntax is forward-compatible with a future PFA
> proposal though.
>
> Regards,
> Nikita
More bikeshedding, sorry. Was a syntax using `fn` considered? Like
$fn = Closure::fromCallable('strlen');
$fn = fn strlen;
or
$fn = (fn) strlen;
Olle
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] First-class callable syntax
On Thu, May 20, 2021 at 2:48 PM Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for a first-class callable syntax, which is > intended as a simpler alternative to the partial function application (PFA) > proposal: > > https://wiki.php.net/rfc/first_class_callable_syntax > > See the Rationale section for details on how this relates to PFA. Over the > past week, we've had a lot of discussions on how exactly PFA is supposed to > work (most of them OTR), and while we seem to have a tentative consensus on > the correct model to use (which does not match the current RFC), it's clear > that this feature has turned out more complicated than originally > anticipated. Joe (who provided the implementation for the PFA RFC) is also > concerned about the implementation complexity that the final model would > require. > > At least I personally was mainly interested in PFA because it provides a > first-class callable syntax as a side-effect. This RFC goes back to > providing *just* that. The syntax is forward-compatible with a future PFA > proposal though. > > Regards, > Nikita > I've updated the RFC to forbid combination with the nullsafe operator, as well as explicitly mention strict types behavior, as these came up in the PFA discussion. I plan to put up this RFC for voting in the event that the PFA proposal does not get accepted. Regards, Nikita
Re: [PHP-DEV] [RFC] Under Discussion: Default User-Agent for cURL
Hi! Would anyone else be in favor of reusing the user_agent setting for cURL despite the BC break? At the moment all possibilities (user_agent, curl.user_agent (PHP_INI_ALL), curl.user_agent (PHP_INI_SYSTEM)) seem to have negative votes attached. I am unsure if it makes sense to go forward with the RFC and if I should bring the RFC to a YES/NO vote for the feature itself and the three mentioned possibilities to choose from as a secondary vote option. I'd love to get some help on how to proceed even if the answer might be: don't proceed. Am So., 27. Juni 2021 um 09:25 Uhr schrieb Aleksander Machniak : > On 27.06.2021 08:48, Michael Maroszek wrote: > > That's what I also thought when making the PR and therefore I initially > > went with PHP_INI_ALL. > > > > But Tyson made a good point that the curl.cainfo is PHP_INI_SYSTEM and we > > might want to be consistent about modes inside an extension. > > Another option might be PHP_INI_PERDIR (for both). Why? Because that's > what's used for (similar) openssl extension configuration. > > ps. anyway, right now I'm on -1 for the new config option. > > -- > Aleksander Machniak > Kolab Groupware Developer[https://kolab.org] > Roundcube Webmail Developer [https://roundcube.net] > > PGP: 19359DC1 # Blog: https://kolabian.wordpress.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Pipe Operator, take 2
2021-06-29 0:54 GMT+02:00, Larry Garfield : > On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote: > >> Mm. Assoc arrays are by now known to be not so good. I hope... > > There are millions of PHP sites build on anonymous arrays today. > >> OCaml is strictly evaluated, not lazy like Haskell. So the order might >> matter, dunno, I don't use this operator often. :) My point was mostly >> that it's very easy to add in OCaml - just one line. And as in >> Haskell, you can define operators in your modules. Similarly, in PHP >> it's easy to do super-dynamic stuff like "new $someclass", which is >> not remotely possible in FP (good or bad, depending on your religion). >> >> Adding a new pipe keyword is like the list() keyword, kind of. A bad >> idea, haha. But I think all stones can be turned, if this RFC now gets >> a no. :/ >> >> Would a slimmed down version have more support? How about removing the >> variadic operator, and let the user manually add the lambda for those >> cases? Could reduce the complexity while still covering maybe 80% of >> the use-cases? Same with removing support for named arguments. So '?' >> would only be a short-cut to get rid of boilerplate like `$strlen = >> fn($x) => strlen($x)`. > > I talked with Joe about this, and the answer is no. Most of the complexity > comes from the initial "this is a function call, oops no, it's a partial > call so we switch to doing that instead", which ends up interacting with the > engine in a lot of different places. Once you've done that, supporting one > placeholder or multiple, variadics or not, etc. is only a small incremental > increase in complexity. > >> > Overall, I really don't like the idea of special-casing pipes to change >> > what >> > symbol table gets looked up. >> >> Still wondering if this could be a per-file or per-library setting >> somehow, to opt-in into pipe behaviour when so desired. Or rather, to >> opt-in into this or that behaviour needed to do more idiomatic pipe. >> >> Here's one boilerplaty pipe: > > *snip* > > We're in the pipe thread here, not PFA. :-) And really, you're solving the > wrong problem. Pipes are trivial. They're only clunky because of PHP's > lack of decent callable syntax. PFA gives us that, but the engine makes the > implementation more complex than it seems like at first glance. > > Trying to come up with complex workarounds to make pipes pretty without > helping anything else is a fool's errand, especially when we have a working > PFA RFC that's about to end voting. (And right now is losing by a very slim > margin, but could pass if a few people change their minds.) > > Aside from something like Nikita's ...-only function reference RFC, which > only handles half the problem (it doesn't do anything to make multi-arg > functions work with pipes at all), any other solution is going to end up > reinventing PFA one way or another, or reinventing existing ugly user-space > libraries. one way or another > > I've not yet decided if I'm going to bring pipes to a vote if PFA doesn't > pass. I'm tempted to, but it would require rewriting all the RFC text back > to the uglier version without PFA, and yeah, it's not going to look as > pretty. And the main pushback a year ago when I first brought it up was > "PFA first, please, so the callable syntax isn't ugly." And... here we > are. > > --Larry Garfield Is there no "pre-vote" process for RFCs? For example, letting the voting members *rate* different alternatives, in a ranking fashion, to see which one is most and least popular. Feels like a lot of work is getting wasted if something is voted down on a small margin. Olle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Readonly properties
>
> Le lun. 28 juin 2021 à 18:22, Larry Garfield a
>> écrit :
>>
>>> On Mon, Jun 28, 2021, at 11:17 AM, Nicolas Grekas wrote:
>>> > > > I'd like to open the discussion on readonly properties:
>>> > > > https://wiki.php.net/rfc/readonly_properties_v2
>>> > > >
>>> > > > This proposal is similar to the
>>> > > > https://wiki.php.net/rfc/write_once_properties RFC that has been
>>> > > declined
>>> > > > previously. One significant difference is that the new RFC limits
>>> the
>>> > > scope
>>> > > > of initializing assignments. I think a key mistake of the previous
>>> RFC
>>> > > was
>>> > > > the confusing "write-once" framing, which is both technically
>>> correct and
>>> > > > quite irrelevant.
>>> > > >
>>> > > > Please see the rationale section (
>>> > > > https://wiki.php.net/rfc/readonly_properties_v2#rationale) for
>>> how this
>>> > > > proposal relates to other RFCs and alternatives.
>>> > > >
>>> > >
>>> > > I plan to open voting on this RFC soon. I don't think there's
>>> anything
>>> > > technical left to address here, the discussion mostly comes down to
>>> a value
>>> > > judgement. I think everyone has made their position regarding that
>>> clear...
>>> > >
>>> >
>>> > Actually, we talked off the list about a way to possibly make this work
>>> > with __clone():
>>> >
>>> > We could allow __clone to have one argument, the object being cloned.
>>> And
>>> > when the signature declares this argument, then all readonly properties
>>> > would be set as uninitialized on $this.
>>> >
>>> > A typical __clone function would look like this with readonly
>>> properties:
>>> > function __clone(object $original)
>>> > {
>>> > $this->readonlyProp = clone $original->readonlyProp;
>>> > }
>>> >
>>> > That would turn my vote into a +1 if that could be made to work!
>>>
>>> That sounds like it would support deep cloning, but not with-er
>>> methods. There's no way to provide a changed value. It also would mean a
>>> lot of work on larger objects to transfer across all the properties. I
>>> don't really see what this would add.
>>>
>>
>> Can you elaborate about the lack of support for withers? Having some work
>> to do doesn't look like an issue to me, especially when there is no
>> alternative to compare that too.
>>
>
> I sent that too fast, I agree about withers... :)
> I'm looking for a way to +1 that RFC...
> Any other idea?
>
And I was too fast agreeing that my proposal to pass the original object as
argument was incompatible with withers.
I also think that not being compatible with deep cloning is a major issue.
Past trivial cases, the use cases I can think of where I would use readonly
require deep cloning. See eg the Symfony Request object where query params,
headers, and a few others expose state as public objects.
Here is some code that just works with them:
class C
{
public readonly string $foo;
public readonly string $bar;
private $skipWhenCloning;
public function withFoo($foo)
{
$this->skipWhenCloning = 'foo';
$clone = clone $this;
$clone->foo = $foo;
}
public function withBar($bar)
{
$this->skipWhenCloning = 'bar';
$clone = clone $this;
$clone->bar = $bar;
}
public function __clone(self $original)
{
foreach ($this as $k => $v) {
if ($k !== $this->skipWhenCloning) {
$this->$k = $original->$k;
}
}
$this->skipWhenCloning = $original->skipWhenCloning = null;
}
}
You might not like the boilerplate, but that just works.
Can this be considered Nikita?
