Re: [PHP-DEV] Re: [RFC] Partial function application
On Sat, May 29, 2021 at 3:50 PM Mark Randall wrote:
>
> On 25/04/2021 20:25, Larry Garfield wrote:
> > It includes an implementation by Joe Watkins that is already about 95%
> > complete. (There's some edge cases he's still sorting out, but all of the
> > typical cases should work already.) Most of the design work comes from
> > Levi Morrison and Paul Crovella. I helped out with the tests, a few edge
> > bits, and general instigator/nudge. :-)
>
>
> Can I be a little pushy and ask for a subvote on "..." vs "...?"
>
> It _probably_ won't matter, but with ... being used as the language's
> universal variadic / unpack, we may use it for similar things in the
> years to come, and I think it makes sense to pre-empt a potential
> conflict or source of confusion down the line by using "...?".
>
> Just as a variadic function argument is ...$ a variadic partial closure
> would be ...?
>
> I do not, at this time, have a firm example of where this might become a
> problem, otherwise I would state it. The closest I can think of for now
> is that it's entirely possible that auto-capturing multiline functions
> may end up using:
>
> $x = function() use (...) { /* */ }
>
> Which could possibly be confusing. Not a definiative example by any
> stretch, but but I do get the feeling that, as we can future proof it
> for effectively zero cost, we should.
>
> Mark Randall
I do like the symmetry:
Positionals:
f($x) --> f(?)
Named:
f(x: $x) --> f(x: ?)
Variadic:
f(...$args) --> f(...?)
You are right that it _might_ be more future compatible. I don't care
about the extra character in this case, as the char does add some
visual cue:
$callback = $serializer->pack(...);
$callback = $serializer->pack(...?);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Partial function application
On 25/04/2021 20:25, Larry Garfield wrote:
It includes an implementation by Joe Watkins that is already about 95%
complete. (There's some edge cases he's still sorting out, but all of the
typical cases should work already.) Most of the design work comes from Levi
Morrison and Paul Crovella. I helped out with the tests, a few edge bits, and
general instigator/nudge. :-)
Can I be a little pushy and ask for a subvote on "..." vs "...?"
It _probably_ won't matter, but with ... being used as the language's
universal variadic / unpack, we may use it for similar things in the
years to come, and I think it makes sense to pre-empt a potential
conflict or source of confusion down the line by using "...?".
Just as a variadic function argument is ...$ a variadic partial closure
would be ...?
I do not, at this time, have a firm example of where this might become a
problem, otherwise I would state it. The closest I can think of for now
is that it's entirely possible that auto-capturing multiline functions
may end up using:
$x = function() use (...) { /* */ }
Which could possibly be confusing. Not a definiative example by any
stretch, but but I do get the feeling that, as we can future proof it
for effectively zero cost, we should.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator
On 29.05.2021 at 10:02, Mel Dafert wrote: >> 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. > > Should this new RFC then only apply to IntlDatePatternGenerator, or should it > also > clarify that future additions to the intl extension (or to extensions in > general?) > should not add both styles and prefer OO style if possible? IMO, an RFC which generally "forbids" the introduction of new dual APIs would make sense. I don't think that we *need* an RFC to remove the procedural API of IntlDatePatternGenerator. Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add IntlDatePatternGenerator
>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. Should this new RFC then only apply to IntlDatePatternGenerator, or should it also clarify that future additions to the intl extension (or to extensions in general?) should not add both styles and prefer OO style if possible? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
