Re: [PHP-DEV] Any interest in a list type?
On Wed, Apr 22, 2020 at 11:03 PM Matthew Brown wrote: > > > This is the *design* process for a language, and it's important... > Stepping back to reconsider how collections work generally, and how we can > improve them in a graceful way that leads to a clean end-state, would be > very valuable. > > Though you have much more experience with internals than I do, I think that > building a consensus around a bold new vision for PHP collections would be > a near-Sisyphean task. > > Adding a list/vector type would be a much smaller, more easily definable > task – it was one of the first new types that Hack added, and by all > accounts they're pretty happy with that decision. IIRC, they switched from object semantics to value semantics (like PHP arrays). Can someone more knowledgeable confirm? > > > Should we also be adding a dedicated dictionary type as well? > > Maybe? I think there'd be less to gain from a performance standpoint > though, so I didn't want to lump that in with any list proposal and risk > derailment. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Any interest in a list type?
> This is the *design* process for a language, and it's important... Stepping back to reconsider how collections work generally, and how we can improve them in a graceful way that leads to a clean end-state, would be very valuable. Though you have much more experience with internals than I do, I think that building a consensus around a bold new vision for PHP collections would be a near-Sisyphean task. Adding a list/vector type would be a much smaller, more easily definable task – it was one of the first new types that Hack added, and by all accounts they're pretty happy with that decision. > Should we also be adding a dedicated dictionary type as well? Maybe? I think there'd be less to gain from a performance standpoint though, so I didn't want to lump that in with any list proposal and risk derailment.
Re: [PHP-DEV] Re: Any interest in a list type?
> > Anyway, I hope this was interesting and can help inform discussion and > perhaps provide inspiration! > This was very useful, and it makes me feel more strongly that list should be an entirely separate type so that checking for packed keys is rarely necessary.
Re: [PHP-DEV] Re: Any interest in a list type?
> For simplicity's sake I haven't > implemented a type declaration right now, just an is_list() function, > but it could easily be extended to one This is a crucial question – should is_list function like is_numeric($some_string), where is_list just tells you about the keys in the array at a given point in the program, or should it function like is_int, where it tells you about the type. I lean towards the latter (which would make the implementation of is_list simpler, but would complicate everything else.
Re: [PHP-DEV] Re: Any interest in a list type?
Hi Andrea, > Since it's pretty simple, I decided to write a proof-of-concept > implementation of such a check. For simplicity's sake I haven't > implemented a type declaration right now, just an is_list() function, > but it could easily be extended to one. The implementation can be found > at https://github.com/php/php-src/compare/master...hikari-no-yume:is_list I wrote in a different response to the original email: > Working to have a vote on https://github.com/php/php-src/pull/4886 might be a > good first step, and something I was personally interested in seeing in > 8.0-dev. I thought I mentioned that there was a PR that implemented is_list() in another email in that thread, but it turns out I was mistaken - I just mentioned the URL. Sorry. That PR "Add is_list function" (https://github.com/php/php-src/pull/4886) copies the is_list implementation that the JSON extension uses internally for efficient serialization of lists. I'm glad to see the interest in support for is_list(), list types, or working on potential implementations. Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Any interest in a list type?
On Apr 21, 2020, at 12:49, Andrea Faulds wrote: > I recall someone previously suggesting (not formally proposing IIRC) we could > have a standard library is_ function to check these, but it didn't go > anywhere. That would be me, and I had a draft implementation for it: https://github.com/php/php-src/pull/4886 My proposal was more oriented towards adding a function to test whether an array was list-like (all keys are sequential integers), though, not adding it as a formal type. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Any interest in a list type?
Hello again everyone,
Andrea Faulds wrote:
Hello again,
Andrea Faulds wrote:
Hi,
Matthew Brown wrote:
I imagine such a "list" type would be a subtype of "array" – everywhere
that array was accepted, a list would be also, and it would have the
same
copy-on-write behaviour.
IIRC with the modern implementation of arrays in the Zend Engine, you
can check that an array has no string keys, has keys in the right
order, and possibly even that they are all numbered 0 through
(count($arr) - 1) without gaps.
Sorry, what I meant to say was “you can check [quickly in O(1) time]
that an array has no string keys [etc]”. This is because of the Zend
Engine's “packed arrays”.
Thanks,
Andrea
Since it's pretty simple, I decided to write a proof-of-concept
implementation of such a check. For simplicity's sake I haven't
implemented a type declaration right now, just an is_list() function,
but it could easily be extended to one. The implementation can be found
at
https://github.com/php/php-src/compare/master...hikari-no-yume:is_list
(and here's a direct commit link to the current version as of this
writing for the sake of historical record:
https://github.com/php/php-src/commit/f6fc94fae8d97743d23d276d66071dac1d240a05)
As I hoped, it can in several common cases give a TRUE result in O(1):
$ sapi/cli/php -r 'var_dump(is_list([]));'
No elements
bool(true)
$ sapi/cli/php -r 'var_dump(is_list([3, 2, 1]));'
Packed and without holes!
bool(true)
$ sapi/cli/php -r '$x = [3,2,1]; sort($x); var_dump(is_list($x));'
Packed and without holes!
bool(true)
$ sapi/cli/php -r '$x = [1,2,3,4]; unset($x[3]); var_dump($x,
is_list($x));'
Packed and without holes!
bool(true)
Unfortunately, it turns out that it can't always be fast! :(
The problem is that while an array can have the “packed” and “without
holes” flags IFF it has no string keys and all keys are in order without
gaps, that does not mean the reverse is true: that if an array lacks
those flags, it must have string keys, out-of-order keys or gaps. The
result is there are several cases where we must foreach over the array
to check if it's a “list”, which unfortunately means as bad as O(n) time
complexity depending on the array content.
For example we can't be sure if it has string keys without foreaching
over it:
$ sapi/cli/php -r 'var_dump(is_list(["foo"=>"bar","bar"=>"baz"]));'
Foreaching
Hit string key
bool(false)
I want to say that this used to be possible in the common case without
foreaching due to some flag on the HashTable, I think Dmitry added that.
But it might have been a proposed patch that didn't get in, or it was
reverted.
If this is check will only be used as a type declaration on
functions/return-types/properties and not as a general-purpose is_list()
function, we might decide that the O(n) worst-case is acceptable so long
as it only affects cases where the array is not a valid list, i.e. when
a TypeError would be thrown, because in production code, values being
type-checked should only rarely have the wrong type, so it should only
cause slowness during debugging. It is not like we are trying to make
throwing type errors fast… at least so I assume?
Unfortunately, this O(n) worst-case applies even to some valid lists.
For example:
$ sapi/cli/php -r '$x = [0=>1,2=>3,1=>2]; unset($x[2]); var_dump($x,
is_list($x));'
Foreaching
No irregularities encountered, true by slowest path
array(2) {
[0]=>
int(1)
[1]=>
int(2)
}
bool(true)
$ sapi/cli/php -r '$x = [1,2,3]; $x["foo"] = "bar"; unset($x["foo"]);
var_dump(is_list($x));'
Foreaching
No irregularities encountered, true by slowest path
bool(true)
Maybe these kinds of cases are uncommon enough that we could deem the
slowness acceptable. We could also use list type-checks as an
opportunity to optimise valid lists that aren't already “packed” to be
“packed” behind-the-scenes, speeding up subsequent checks. Also, it may
be the case that the Zend Engine's hashtable implementation could be
changed slightly to allow O(1) checks in more cases.
Anyway, I hope this was interesting and can help inform discussion and
perhaps provide inspiration!
Thanks,
Andrea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Any interest in a list type?
On Wed, Apr 22, 2020, at 3:44 PM, Matthew Brown wrote: > > map/filter/reduce need to be recast to work on any iterable, which would > then include lists > > Lists would only make sense if we're also rethinking how collections work > generally > > I disagree – I think the most successful PHP language additions have been > those that allow PHP developers to improve their code without having to > think too hard – for example, property, return and param types can be added > to existing code without changing its behaviour at runtime, as long as the > added types align with actual behaviour. > > If list types work in a wholly different fashion to arrays, they won't be a > drop-in-replacement, they won't feel familiar to the average PHP developer, > and I imagine few people would update existing code to use them, because > it'd be too risky. 1) Please don't top-post. 2) I don't mean "make them as unlike arrays as possible". I mean "think through the implications of having a *third* type of iterable; what other functions would be affected? Should we reconsider how map/filter/reduce work generally instead of just throwing a bunch more random functions at it? What are the knock-on effects? Should we also be adding a dedicated dictionary type as well? Why or why not?" This is the *design* process for a language, and it's important. "Let's just throw a numeric-only list type into the pool and see what happens" is a very bad idea. Stepping back to reconsider how collections work generally, and how we can improve them in a graceful way that leads to a clean end-state, would be very valuable. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function pipe operator
Haskell has & operator in Data.Function module which is exact equivalent of the proposed feature. Link: https://hackage.haskell.org/package/base-4.8.0.0/docs/Data-Function.html#g:2 Example: https://repl.it/repls/KindLightsalmonApplicationserver On Wed, Apr 22, 2020 at 9:09 PM Larry Garfield wrote: > On Wed, Apr 22, 2020, at 3:25 AM, Guilliam Xavier wrote: > > On Tue, Apr 21, 2020 at 4:44 PM Larry Garfield > wrote: > > > > > > On Mon, Apr 20, 2020, at 11:20 PM, Stanislav Malyshev wrote: > > > > Just a small pedantry note - in a comparison section, the RFC > compares > > > > this syntax to function composition. But this is not function > > > > composition. This is a syntax sugar for calling two functions one > after > > > > another, not operator that produces a function. It sounds pedantic > but > > > > it's rather important distinction - if |> is composition, than $foo > |> > > > > $bar is a new callable provided $foo and $bar are callable (but no > > > > function is actually being called here!). If |> is call syntax, it's > > > > actually the result of calling $bar($foo). > > > > > > > > So comparing it to function composition is a bit confusing. > Otherwise it > > > > looks OK to me, except the syntax for calling functions and methods > is a > > > > bit awkward, but it's not the problem of this RFC I imagine. > > > > > > I'm not sure I follow. The only place composition is mentioned is in > the F# section, where it calls out specifically that we're implementing > "pipe forward" and *not* the composition operators ( >> ). Is that unclear? > > > > Actually it's also mentioned in the Haskell section, but as "function > > concatenation" (which adds to the confusion I guess). > > Ah, I see what you mean. I've adjusted that section to be clearer about > what Haskell does. > > > Speaking of Haskell, that reminded me of > > http://learnyouahaskell.com/a-fistful-of-monads#walk-the-line where > > the author defines a custom `-:` operator such that `x -: f` desugars > > to `f x` (equivalent to how `$x |> $f` would desugar to `$f($x)` with > > the RFC), which allows to write e.g. `xs -: sort -: reverse` instead > > of `reverse (sort xs)` or `(reverse . sort) xs`. > > If I ever actually wrote Haskell, I'd find that extremely useful. :-) > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] Any interest in a list type?
> map/filter/reduce need to be recast to work on any iterable, which would then include lists > Lists would only make sense if we're also rethinking how collections work generally I disagree – I think the most successful PHP language additions have been those that allow PHP developers to improve their code without having to think too hard – for example, property, return and param types can be added to existing code without changing its behaviour at runtime, as long as the added types align with actual behaviour. If list types work in a wholly different fashion to arrays, they won't be a drop-in-replacement, they won't feel familiar to the average PHP developer, and I imagine few people would update existing code to use them, because it'd be too risky. On Wed, 22 Apr 2020 at 15:01, Larry Garfield wrote: > On Wed, Apr 22, 2020, at 1:49 PM, Matthew Brown wrote: > > > Is it an effective subtype of array? > > > > I was thinking it should be (with the auto-conversion mentioned above), > but > > I can see a compelling case to not have the auto-conversion when > > manipulating – while it would bloat the stdlib a little (we'd need a > whole > > bunch of list_* functions) the separation would simplify things a lot > (e.g. > > list_filter would return a list with sequential keys, whereas > array_filter > > returns an array with possibly non-sequential keys) > > > > And then you could cast between the two like "(list) $some_array" (which > > would preserve order but remove keys) and "(array) $some_list" as > > necessary. There could even be some automatic list <-> array casting when > > calling functions not in strict_types mode. > > > > > Should they pass like arrays or like objects > > > > Definitely like arrays – I want them to be a drop-in-replacement for > people > > who currently use arrays in places lists are more appropriate. > > > > > Should they be mutable or immutable > > > > Definitely mutable, like arrays are > > That has a long list of possible issues with it relating to spooky action > at a distance, depending on the passing semantics. In some languages lists > are immutable, and with PHP's copy-on-write it may make more sense to just > go immutable. > > > > Are they iterable > > > > Yes, the keys are sequential integers > > > > > Does it make sense to add them without type enforcement via generics > > > > Absolutely – this shouldn't be tied to generics landing (which I'd > imagine > > is a PHP 9 feature at this point, whereas this could be a PHP 8.x > feature). > > > > > can they be mapped/filtered/reduced > > > > Absolutely – I think we'd have list_map, list_filter, list_reduce > functions > > to provide that functionality. > > Why duplicate all of them? Rather, map/filter/reduce need to be recast to > work on any iterable, which would then include lists. Or, if lists are an > object they would be methods on the object. > > Hence my point. Lists would only make sense if we're also rethinking how > collections work generally, for which we're already overdue. Just tossing > them in as yet-another-different-thing would make the situation worse, not > better. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Any interest in a list type?
On Wed, Apr 22, 2020, at 1:49 PM, Matthew Brown wrote: > > Is it an effective subtype of array? > > I was thinking it should be (with the auto-conversion mentioned above), but > I can see a compelling case to not have the auto-conversion when > manipulating – while it would bloat the stdlib a little (we'd need a whole > bunch of list_* functions) the separation would simplify things a lot (e.g. > list_filter would return a list with sequential keys, whereas array_filter > returns an array with possibly non-sequential keys) > > And then you could cast between the two like "(list) $some_array" (which > would preserve order but remove keys) and "(array) $some_list" as > necessary. There could even be some automatic list <-> array casting when > calling functions not in strict_types mode. > > > Should they pass like arrays or like objects > > Definitely like arrays – I want them to be a drop-in-replacement for people > who currently use arrays in places lists are more appropriate. > > > Should they be mutable or immutable > > Definitely mutable, like arrays are That has a long list of possible issues with it relating to spooky action at a distance, depending on the passing semantics. In some languages lists are immutable, and with PHP's copy-on-write it may make more sense to just go immutable. > > Are they iterable > > Yes, the keys are sequential integers > > > Does it make sense to add them without type enforcement via generics > > Absolutely – this shouldn't be tied to generics landing (which I'd imagine > is a PHP 9 feature at this point, whereas this could be a PHP 8.x feature). > > > can they be mapped/filtered/reduced > > Absolutely – I think we'd have list_map, list_filter, list_reduce functions > to provide that functionality. Why duplicate all of them? Rather, map/filter/reduce need to be recast to work on any iterable, which would then include lists. Or, if lists are an object they would be methods on the object. Hence my point. Lists would only make sense if we're also rethinking how collections work generally, for which we're already overdue. Just tossing them in as yet-another-different-thing would make the situation worse, not better. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Any interest in a list type?
> Is it an effective subtype of array? I was thinking it should be (with the auto-conversion mentioned above), but I can see a compelling case to not have the auto-conversion when manipulating – while it would bloat the stdlib a little (we'd need a whole bunch of list_* functions) the separation would simplify things a lot (e.g. list_filter would return a list with sequential keys, whereas array_filter returns an array with possibly non-sequential keys) And then you could cast between the two like "(list) $some_array" (which would preserve order but remove keys) and "(array) $some_list" as necessary. There could even be some automatic list <-> array casting when calling functions not in strict_types mode. > Should they pass like arrays or like objects Definitely like arrays – I want them to be a drop-in-replacement for people who currently use arrays in places lists are more appropriate. > Should they be mutable or immutable Definitely mutable, like arrays are > Are they iterable Yes, the keys are sequential integers > Does it make sense to add them without type enforcement via generics Absolutely – this shouldn't be tied to generics landing (which I'd imagine is a PHP 9 feature at this point, whereas this could be a PHP 8.x feature). > can they be mapped/filtered/reduced Absolutely – I think we'd have list_map, list_filter, list_reduce functions to provide that functionality. On Wed, 22 Apr 2020 at 13:28, Larry Garfield wrote: > On Tue, Apr 21, 2020, at 2:00 PM, Matthew Brown wrote: > > Before I create an RFC or attempt a reference implementation, is there > any > > interest in adding (and then obviously supporting in perpetuity) a list > > type? > > > > The first line of PHP's documentation for "array" states: "An array in > PHP > > is actually an ordered map". There are some optimisations that make > arrays > > with ordered integer keys faster, but I'd be interested in a separate > type > > dedicated to *sequential* integer keys. Such a type would presumably > > consume a little less memory. > > > > Why "list" and not "vec" or similar? "list" is also a reserved word – I'm > > imagining that you'd construct a list like > > > > $l = list["a", "b", "c"]; > > > > I imagine such a "list" type would be a subtype of "array" – everywhere > > that array was accepted, a list would be also, and it would have the same > > copy-on-write behaviour. > > > > If people are interested in having that type, there's a question of what > to > > do with > > > > $some_list["a"] = 5; > > > > Would you convert the $some_list to an array, or throw an exception? > > Converting to an array would seem the more PHP-like thing to do. > > > > Similarly, the behaviour of > > > > $some_list[$key_out_of_current_range] = 5 > > > > would be a matter of debate too – would that turn $some_list into an > array, > > or would it fill up any preceding entries in the array with null? > > > > What other questions are there? Is a "list" type even a good fit for PHP, > > given most of its users seem pretty content with the current > > swiss-army-knife array type? > > Most users don't realize that PHP's arrays-not-really-arrays have caused > millions of dollars in security breaches in the past. :-) They're > dangerous and to be avoided whenever possible. > > I'm very open to a list/sequence type, but as others have noted there's a > whole crapload of details to sort out to make it viable. In particular: > > * Is it an effective subclass of array? IMO, no. It should have > absolutely no auto-conversion to/from an array whatsoever of any kind, > period. Keep them as separate as possible. > > * Should it even have random-access indexes? Honestly I'd say no; Just > support adding, removing, and iteration and generate the indexes on the fly > when iterating if necessary. > > * Should they pass like arrays or like objects? Many questions here. > > * Should they be mutable or immutable? I could argue for either one > effectively, I think, though I'd honestly favor immutable. > > * Are they iterable? Presumably, but does that have any weird > implications for iterables that implicitly assume there are keys? How's > that work? > > * Does it make sense to add them without type enforcement via generics? > Lists + Generics would be lovely, but as we've seen Generics are Hard(tm) > and Not Imminent(tm). But would adding them now make a generic version > harder in the future? (I've no idea.) > > * Besides add/remove/iterate, what other baked-in functionality should > they have? Eg, can they be mapped/filtered/reduced? It would really suck > to revisit lists and not fix that disconnect in the API. (Insert me > talking about comprehensions and stuff here.) Ideally this would happen as > part of a larger review of how collections work at various levels, which > are currently highly clunky. > > Those are all solvable problems (and I've likely forgotten several), but > they would have to be thought through extensively before an
[PHP-DEV] [VOTE] Round two, PHP 8.0 RM
Hi, as I mentioned, the first STV round ran into a tie, so there is a current run-off between the two candidates that tied, Gabriel and Ben, at: https://wiki.php.net/todo/php80#round_two 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] Typed callable properties
Hello,
thank you for expanding on your comparison of callables to resources. I didn't
completely understand what you meant but now I do.
Speaking of "dynamic" callables - this is also one of the reasons as to why I
believe we shouldn't wait for typedefs and should allow properties to be typed
as callable (just like parameters/return type). Don't get me wrong, I fully
agree that we should have more strict callables and an ability to specify their
signatures if they are static (in a sense that they don't change) and not
dynamic. But in cases like the one I mentioned, all we can do is specify that
we accept any callable.
Best regards,
Benas Seliuginas
‐‐‐ Original Message ‐‐‐
On Wednesday, April 22, 2020 8:39 PM, Michał Brzuchalski
wrote:
> Hi Benas,
>
> my responses below.
>
> śr., 22 kwi 2020 o 19:17 moliata napisał(a):
>
>> Hello,
>>
>> thank you for an opinion as well! While I do fully agree that callable type
>> needs to be improved with features such as typedefs, I found a couple of
>> problems in your response.
>>
>> First of all, I wouldn't say that the callable type provides little-to-no
>> information like the resource type. A resource can only be made by specific
>> functions such as `fopen()` and are bound to specific use
>> cases/implementations
>> e. g. MySQL resources are only for MySQL database access. Meanwhile,
>> callables
>> can be made "freely" (couldn't find a better word :-)) like integers or
>> booleans and also in some cases don't have an exact function signature. One
>> such example I mention in the next paragraph.
>
> I only said that it brings as much value as a resource type in usage context.
>
> Given a resource type constraint on function argument doesn't say anything to
> you
> as a consumer, you cannot just use that resource without knowledge of its type
> the only thing you could do is calling a get_resource_type(resource
> $resource) function.
>
> The same applies to callable, given callable like: 'strtolower',
> [DateTimeImmutable::class, 'createFromFormat']
> or fn(int $x): $x*2; and when that came to your function with callable type
> constraint
> you also don't know how to use it without some reflection inspection cause
> the type doesn't bring much value.
>
> While fulfilling for eg. delegate gives you guarantee that when a
> callable/closure is passed it matches
> your expectations and you can use it right away without reflection
> inspections.
> You no longer need additional data to use the variable which applies to
> callable and resource as well.
>
>> Speaking of a snippet you showed, I'm not sure how that implementation would
>> work with "dynamic" callables. For example let's assume we have a framework
>> that allows registering routes with placeholders to controllers, like this:
>> `$router->register('/post/{id}', [$controller, 'show']); // this would pass a
>> single parameter to the callable`
>> `$router->register('/user/{id}/post/{id}', [$controller, 'showFromUser']); //
>> this would pass two parameters to the callable`
>> ...in this case, we can't know how many placeholders/parameters a function
>> can
>> have as that depends on how many placeholders are in the string. A framework
>> can only resolve these at runtime.
>
> True. In this case, it'd be hard to create a static constraint for
> callable/closure check
> but actually this is not the case we're looking for. Things where mentioned
> delegate
> match perfectly is the places where your expectations to the callable/closure
> type
> are static and known at the time when writing code.
>
> Given that in a situation when the input and the output types are known this
> would bring the benefit of runtime check before use.
>
> Cheers,
> Michał Brzuchalski
Re: [PHP-DEV] [RFC] Function pipe operator
On Wed, Apr 22, 2020, at 3:25 AM, Guilliam Xavier wrote: > On Tue, Apr 21, 2020 at 4:44 PM Larry Garfield wrote: > > > > On Mon, Apr 20, 2020, at 11:20 PM, Stanislav Malyshev wrote: > > > Just a small pedantry note - in a comparison section, the RFC compares > > > this syntax to function composition. But this is not function > > > composition. This is a syntax sugar for calling two functions one after > > > another, not operator that produces a function. It sounds pedantic but > > > it's rather important distinction - if |> is composition, than $foo |> > > > $bar is a new callable provided $foo and $bar are callable (but no > > > function is actually being called here!). If |> is call syntax, it's > > > actually the result of calling $bar($foo). > > > > > > So comparing it to function composition is a bit confusing. Otherwise it > > > looks OK to me, except the syntax for calling functions and methods is a > > > bit awkward, but it's not the problem of this RFC I imagine. > > > > I'm not sure I follow. The only place composition is mentioned is in the > > F# section, where it calls out specifically that we're implementing "pipe > > forward" and *not* the composition operators ( >> ). Is that unclear? > > Actually it's also mentioned in the Haskell section, but as "function > concatenation" (which adds to the confusion I guess). Ah, I see what you mean. I've adjusted that section to be clearer about what Haskell does. > Speaking of Haskell, that reminded me of > http://learnyouahaskell.com/a-fistful-of-monads#walk-the-line where > the author defines a custom `-:` operator such that `x -: f` desugars > to `f x` (equivalent to how `$x |> $f` would desugar to `$f($x)` with > the RFC), which allows to write e.g. `xs -: sort -: reverse` instead > of `reverse (sort xs)` or `(reverse . sort) xs`. If I ever actually wrote Haskell, I'd find that extremely useful. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typed callable properties
Hello,
thank you for the comment! Yes, indeed I was raising a discussion on whether we
should allow making typed callable properties for improved language's
consistency (given that parameter/return type hints can be set to callable). As
one of the solutions, I mentioned that we could just ignore the
scope/context-dependent problems for the time being.
In regards to your comment on `Closure::fromCallable()`, I do also agree that
it is quite verbose and a potential performance hit and as such, this isn't the
way to go. As an example, let's imagine a framework that allows registering
routes to callables. If we wanted to completely type-hint the entire framework,
we would have to make typed Closure properties and in the `addRoute()` function
used `Closure::fromCallable()` to convert every single callable into a closure
object. So, huge applications with thousands of routes would be potentially
affected by this additional overhead.
Best regards,
Benas Seliuginas
‐‐‐ Original Message ‐‐‐
On Wednesday, April 22, 2020 7:30 PM, Rowan Tommins
wrote:
> On 22/04/2020 16:01, Michał Brzuchalski wrote:
>
> > I agree, a callable brings as much information as a resource type - you
> > know the type
> > but are unable to use it without additional information.
>
> While this is true, it's somewhat orthogonal to the question Benas
> raised in this thread - namely, how to handle values that are callable
> in one scope but not another.
>
> That is, is the following code valid (error-free) or not?
>
> delegate Reducer (?int $sum, int $item = 0): int;
> class X {
> private static function myPrivateMethod(?int $sum, int $item = 0):
> int {
> return 0;
> }
> public static function runReducer(Reducer $r) {
> return $r(0, 0);
> }
> }
> echo X::bar(['X', 'myPrivateMethod']);
>
> The equivalent code with a type constraint of "callable" currently runs
> fine, even though passing the same value to a different function would
> fail due to scoping. Making the delegate-constrained version throw an
> error for any private or protected method would just trade one
> inconsistency for another.
>
> A more reasonable restriction, IMO, would be to say that delegates only
> match Closure instances (and possibly other objects with a public
> __invoke method), not the various string and array syntaxes that
> "callable" currently allows. The case above would then need to bind the
> private method into a closure that is callable everywhere, e.g. using
> Closure::fromCallable([self::class, 'myPrivateMethod']);
>
> The obvious downside is that Closure::fromCallable is both verbose and a
> potential performance hit. So it seems we're back again to wanting a new
> syntax to succinctly and optimally generate such a closure. For
> instance, in the discussion of ::func, one suggestion was
> "$closure={self::myPrivateMethod};" and more recently it was mentioned
> that a variant of partial application is to not actually bind anything,
> and write "$closure=self::myPrivateMethod(?, ?);"
>
> Regards,
>
>
>
> Rowan Tommins (né Collins)
> [IMSoP]
>
> ---
>
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To
Re: [PHP-DEV] Typed callable properties
Hi Benas,
my responses below.
śr., 22 kwi 2020 o 19:17 moliata napisał(a):
> Hello,
>
> thank you for an opinion as well! While I do fully agree that callable type
> needs to be improved with features such as typedefs, I found a couple of
> problems in your response.
>
> First of all, I wouldn't say that the callable type provides little-to-no
> information like the resource type. A resource can only be made by specific
> functions such as `fopen()` and are bound to specific use
> cases/implementations
> e. g. MySQL resources are only for MySQL database access. Meanwhile,
> callables
> can be made "freely" (couldn't find a better word :-)) like integers or
> booleans and also in some cases don't have an exact function signature. One
> such example I mention in the next paragraph.
>
I only said that it brings as much value as a resource type in usage
context.
Given a resource type constraint on function argument doesn't say anything
to you
as a consumer, you cannot just use that resource without knowledge of its
type
the only thing you could do is calling a get_resource_type(resource
$resource) function.
The same applies to callable, given callable like: 'strtolower',
[DateTimeImmutable::class, 'createFromFormat']
or fn(int $x): $x*2; and when that came to your function with callable type
constraint
you also don't know how to use it without some reflection inspection cause
the type doesn't bring much value.
While fulfilling for eg. delegate gives you guarantee that when a
callable/closure is passed it matches
your expectations and you can use it right away without reflection
inspections.
You no longer need additional data to use the variable which applies to
callable and resource as well.
Speaking of a snippet you showed, I'm not sure how that implementation would
> work with "dynamic" callables. For example let's assume we have a framework
> that allows registering routes with placeholders to controllers, like this:
> `$router->register('/post/{id}', [$controller, 'show']); // this would
> pass a
> single parameter to the callable`
> `$router->register('/user/{id}/post/{id}', [$controller, 'showFromUser']);
> //
> this would pass two parameters to the callable`
> ...in this case, we can't know how many placeholders/parameters a function
> can
> have as that depends on how many placeholders are in the string. A
> framework
> can only resolve these at runtime.
>
True. In this case, it'd be hard to create a static constraint for
callable/closure check
but actually this is not the case we're looking for. Things where mentioned
delegate
match perfectly is the places where your expectations to the
callable/closure type
are static and known at the time when writing code.
Given that in a situation when the input and the output types are known
this would bring the benefit of runtime check before use.
Cheers,
Michał Brzuchalski
[PHP-DEV] Moving json extension to core?
Hi internals,
Currently, it's possible to disable the json extension with `./configure
--disable-json`.
However, JSON is widely used in many use cases - web sites, logging output, and
as a data format that can be used in CLI programs
to share data with many applications and programming languages, so I'd
personally find it useful if it was always enabled.
(e.g. to publish self-contained scripts that don't require polyfills or less
readable var_export output)
https://wiki.php.net/rfc/jsond mentions that
> The current Json Parser in the json extension does not have a free license
> which is a problem for many Linux distros.
> This has been referenced at Bug #63520. That results in not packaging json
> extension in the many Linux distributions.
Starting in php 7.0, I'd assume licensing is no longer an issue (correct me if
I'm wrong). I don't see anything discussed in the RFC or a quick search of
email threads about making JSON impossible to disable.
Doing this would also make some extensions more convenient to use (e.g.
memcached with the json serializer, using json encoding for uses such as error
messages in miscellaneous extensions, etc.)
P.S. What are your thoughts about adding additional conversion specifiers such
as %j or %v to PHP to call JSON with the default options.
It's a feature similar to those I've seen in programming languages such as
golang - https://golang.org/pkg/fmt/#hdr-Printing
- `printf("console.log("value from php", %j);\n", $value)`
- `printf("Some command returned %j\n", $boolValue)`
Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typed callable properties
Hello,
thank you for an opinion as well! While I do fully agree that callable type
needs to be improved with features such as typedefs, I found a couple of
problems in your response.
First of all, I wouldn't say that the callable type provides little-to-no
information like the resource type. A resource can only be made by specific
functions such as `fopen()` and are bound to specific use cases/implementations
e. g. MySQL resources are only for MySQL database access. Meanwhile, callables
can be made "freely" (couldn't find a better word :-)) like integers or
booleans and also in some cases don't have an exact function signature. One
such example I mention in the next paragraph.
Speaking of a snippet you showed, I'm not sure how that implementation would
work with "dynamic" callables. For example let's assume we have a framework
that allows registering routes with placeholders to controllers, like this:
`$router->register('/post/{id}', [$controller, 'show']); // this would pass a
single parameter to the callable`
`$router->register('/user/{id}/post/{id}', [$controller, 'showFromUser']); //
this would pass two parameters to the callable`
...in this case, we can't know how many placeholders/parameters a function can
have as that depends on how many placeholders are in the string. A framework
can only resolve these at runtime.
Best regards,
Benas Seliuginas
‐‐‐ Original Message ‐‐‐
On Wednesday, April 22, 2020 6:01 PM, Michał Brzuchalski
wrote:
> Hi all,
>
> śr., 22 kwi 2020 o 16:29 Dan Ackroyd napisał(a):
>
>> On Tue, 21 Apr 2020 at 14:08, moliata wrote:
>>>
>>
>>> I wanted to ignite a friendly discussion whether
>>> PHP should allow typed callable properties.
>>
>> IMO no.
>
> I agree, a callable brings as much information as a resource type - you know
> the type
> but are unable to use it without additional information.
>
>> Trying to fix the problems with callables would be a huge amount of
>> work, and not actually give that much benefit. Even just documenting
>> the problems with callables* is a non-trivial amount of work, and I
>> suspect there are many horrors lurking with the SPL code related to
>> them.
>>
>>> I believe we should look into...
>>
>> I'm pretty sure that choosing a different problem to solve that:
>>
>> * would be easier to solve.
>> * provide more benefit in the long term.
>> * not require breaking a lot of userland + internal code immediately,
>> but instead allow for migration over a longer period.
>
> I was pinged by Dan with typedef topic nearly 3 weeks ago and then started
> thinking of the way to define callable types with some initial implementation.
> I chose pattern known from other languages like C# where there are types
> known as delegates.
>
> And so far got to the last line of snippet below where I have to figure out
> some clever type checking with closure:
>
> delegate Reducer (?int $sum, int $item = 0): int;
>
> class Foo implements Reducer {
> public function __invoke(?int $sum, int $item = 0): int {
> return ($sum ?? 0) + $item;
> }
> }
> function reduce(Reducer $reducer) {
> var_dump($reducer(0, 5));
> }
> reduce(new Foo());
> reduce(fn(?int $sum, int $item = 0): int => 8);
> The delegate declaration resolves to an interface with __invoke method which
> therefore can be easily checked
> when the invokable object passed and that information can be easily cached.
> Probably it can be cached also for closures
> and functions but didn't get so far with the implementation yet.
>
> I was also asked why not a general use typedef which can be used to alias any
> kind of type not only a callable.
> But the reason why I chose delegates was that IMO typedef is more like an
> aliasing mechanism, which means
> all that is possible to be aliased should also be possible to be unaliased
> and pasted in all type constraints used in
> function/method parameters as well as class properties.
>
> Meaning if we allow: typedef reducer = callable(?int $sum, int $item = 0):
> int;
> We should also allow: function(callable(?int $sum, int $item = 0): int
> $reducer) {}
> Which IMO looks too verbose and that's why I think a delegate might be a good
> idea as a way to provide
> callable types checking.
>
> Any thoughts are highly appreciated!
>
> Cheers,
> Michał Brzuchalski
Re: [PHP-DEV] Any interest in a list type?
On Tue, Apr 21, 2020, at 2:00 PM, Matthew Brown wrote: > Before I create an RFC or attempt a reference implementation, is there any > interest in adding (and then obviously supporting in perpetuity) a list > type? > > The first line of PHP's documentation for "array" states: "An array in PHP > is actually an ordered map". There are some optimisations that make arrays > with ordered integer keys faster, but I'd be interested in a separate type > dedicated to *sequential* integer keys. Such a type would presumably > consume a little less memory. > > Why "list" and not "vec" or similar? "list" is also a reserved word – I'm > imagining that you'd construct a list like > > $l = list["a", "b", "c"]; > > I imagine such a "list" type would be a subtype of "array" – everywhere > that array was accepted, a list would be also, and it would have the same > copy-on-write behaviour. > > If people are interested in having that type, there's a question of what to > do with > > $some_list["a"] = 5; > > Would you convert the $some_list to an array, or throw an exception? > Converting to an array would seem the more PHP-like thing to do. > > Similarly, the behaviour of > > $some_list[$key_out_of_current_range] = 5 > > would be a matter of debate too – would that turn $some_list into an array, > or would it fill up any preceding entries in the array with null? > > What other questions are there? Is a "list" type even a good fit for PHP, > given most of its users seem pretty content with the current > swiss-army-knife array type? Most users don't realize that PHP's arrays-not-really-arrays have caused millions of dollars in security breaches in the past. :-) They're dangerous and to be avoided whenever possible. I'm very open to a list/sequence type, but as others have noted there's a whole crapload of details to sort out to make it viable. In particular: * Is it an effective subclass of array? IMO, no. It should have absolutely no auto-conversion to/from an array whatsoever of any kind, period. Keep them as separate as possible. * Should it even have random-access indexes? Honestly I'd say no; Just support adding, removing, and iteration and generate the indexes on the fly when iterating if necessary. * Should they pass like arrays or like objects? Many questions here. * Should they be mutable or immutable? I could argue for either one effectively, I think, though I'd honestly favor immutable. * Are they iterable? Presumably, but does that have any weird implications for iterables that implicitly assume there are keys? How's that work? * Does it make sense to add them without type enforcement via generics? Lists + Generics would be lovely, but as we've seen Generics are Hard(tm) and Not Imminent(tm). But would adding them now make a generic version harder in the future? (I've no idea.) * Besides add/remove/iterate, what other baked-in functionality should they have? Eg, can they be mapped/filtered/reduced? It would really suck to revisit lists and not fix that disconnect in the API. (Insert me talking about comprehensions and stuff here.) Ideally this would happen as part of a larger review of how collections work at various levels, which are currently highly clunky. Those are all solvable problems (and I've likely forgotten several), but they would have to be thought through extensively before an implementation could be viable. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typed callable properties
Hello, thank you for your opinion. In response to you mentioning that fixing this problem would be a huge amount of work, I would like to reiterate the idea of simply ignoring context-dependent problems for the time being. In fact, we can observe this behavior in parameter/return type hints already. As such, it doesn't make sense to make just property type hints a special case/exception. Moreover, I oversaw Sara Golemon's comment in the `mixed pseudo type` RFC that she would like to use type aliasing and union types instead, at least in the long run. The problem that comes up with this approach is that even if we did something like this: `use mixed as string|int|...|callable;` ...we couldn't apply this `mixed` type alias to properties as callable type is not allowed to be used with them. Best regards, Benas Seliuginas ‐‐‐ Original Message ‐‐‐ On Wednesday, April 22, 2020 5:29 PM, Dan Ackroyd wrote: > On Tue, 21 Apr 2020 at 14:08, moliata moli...@protonmail.com wrote: > > > > > > I wanted to ignite a friendly discussion whether > > PHP should allow typed callable properties. > > IMO no. > > Trying to fix the problems with callables would be a huge amount of > work, and not actually give that much benefit. Even just documenting > the problems with callables* is a non-trivial amount of work, and I > suspect there are many horrors lurking with the SPL code related to > them. > > > I believe we should look into... > > I'm pretty sure that choosing a different problem to solve that: > > - would be easier to solve. > - provide more benefit in the long term. > - not require breaking a lot of userland + internal code immediately, > but instead allow for migration over a longer period. > > My thoughts on adding 'function types' are here: > https://github.com/Danack/FunctionTypes/blob/master/function_type_rfc.md > > There's still more than a couple of known problems that need to be > worked through, as well as probably unknown problems lurking. As email > is not a good format for carrying out discussions, if people want to > take part in that discussion, doing it in that repo would be better > imo. > > Assuming the problems remaining can be addressed, that would give us a > more useful feature, and the existing 'callables' can be slowly > deprecated and maybe removed from PHP in the distant future. > > cheers > Dan > Ack > > *[problems with callables] - https://wiki.php.net/rfc/consistent_callables > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typed callable properties
On 22/04/2020 16:01, Michał Brzuchalski wrote:
I agree, a callable brings as much information as a resource type - you
know the type
but are unable to use it without additional information.
While this is true, it's somewhat orthogonal to the question Benas
raised in this thread - namely, how to handle values that are callable
in one scope but not another.
That is, is the following code valid (error-free) or not?
delegate Reducer (?int $sum, int $item = 0): int;
class X {
private static function myPrivateMethod(?int $sum, int $item = 0):
int {
return 0;
}
public static function runReducer(Reducer $r) {
return $r(0, 0);
}
}
echo X::bar(['X', 'myPrivateMethod']);
The equivalent code with a type constraint of "callable" currently runs
fine, even though passing the same value to a different function would
fail due to scoping. Making the delegate-constrained version throw an
error for any private or protected method would just trade one
inconsistency for another.
A more reasonable restriction, IMO, would be to say that delegates only
match Closure instances (and possibly other objects with a public
__invoke method), not the various string and array syntaxes that
"callable" currently allows. The case above would then need to bind the
private method into a closure that is callable everywhere, e.g. using
Closure::fromCallable([self::class, 'myPrivateMethod']);
The obvious downside is that Closure::fromCallable is both verbose and a
potential performance hit. So it seems we're back again to wanting a new
syntax to succinctly and optimally generate such a closure. For
instance, in the discussion of ::func, one suggestion was
"$closure={self::myPrivateMethod};" and more recently it was mentioned
that a variant of partial application is to not actually bind anything,
and write "$closure=self::myPrivateMethod(?, ?);"
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] Any interest in a list type?
Thanks for your comments!
> How would array_shift(), array_merge(array, list) ... be handled? Would
they return lists or arrays?
I think they would return lists where appropriate – Psalm & Phan already
infer some of that behaviour, adding runtime support would be an
undertaking, but not impossible.
> References to list typed properties may cause problems...
I don't see this as being any different to how integer typed properties
work under float addition (as below) – we'd just not allow any modification
that violated the list type.
class X { public int $i = 0; }
$x = new X();
$x->i += 2.3;
echo $x->i; // 2, not 2.3
With declare(strict_types=1), the above is a fatal error – the same would
be true for operations that violated list typed properties
> Having them limited to param type and return type checks
Would be happy for that compromise if the above proved confusing, or
difficult to implement
On Tue, 21 Apr 2020 at 20:18, tyson andre wrote:
> Miscellaneous thoughts on this:
>
> - Working to have a vote on https://github.com/php/php-src/pull/4886
> might be a good first step, and something I was personally interested in
> seeing in 8.0-dev.
> However, in the event you can't rule out that is_array($listParam) might
> not return true in the final implementation you decide on, maybe wait. (you
> said it'd be a subtype, and it seems like a lot of code would break, so
> that seems unlikely)
> - How would array_shift(), array_merge(array, list), array_intersect,
> etc., preg_match(), etc be handled? Would they return lists or arrays?
> - I'd really have liked to see data structures such as sets,
> variable-length vectors, etc. in core natively available as objects (or
> other types, but objects seemed the most practical).
> Right now, there's php-ds https://www.php.net/manual/en/book.ds.php ,
> but if I wanted to use vec/list in an application/library that was used in
> a wide variety of places, I'd really rather have something in core. (the
> drawbacks of using a polyfill would outweigh the performance benefits for a
> small fraction of adopters)
> - If those data types were natively available, maybe opcache and/or the
> jit could use specialized opcodes to reduce the overhead of offsetGet,
> etc., if the class was known.
> - References to list iyped properties `class X { public list $list; }
> $x->list = &$localVar; unset($localVar[1]);` may cause problems in
> implementation details if they're a subtype of arrays.
>Forbidding them in typed properties and limiting the type to params and
> return types may work.
> - Having them limited to param type and return type checks (including some
> internal global function return types) would be how I'd prefer it (instead
> of adding a separate type elsewhere)
> PHP already has special handling for iterable/callable.
> - Future scope of a list type hint might be to add a deprecation notice
> for `list ($x, $y) = $array` or `foreach ($x as list($y)) to avoid confusion
> (even though it's currently unambiguous, and that probably will remain
> unambiguous)
>
> - Tyson
Re: [PHP-DEV] Typed callable properties
Hi Dan, On 22/04/2020 15:29, Dan Ackroyd wrote: As email is not a good format for carrying out discussions, if people want to take part in that discussion, doing it in that repo would be better imo. I would be grateful if you could engage in the thread I started last time you suggested something similar, so we can understand what people think the problems with the current mailing list (and wiki) are, and what tools might help solve them. https://externals.io/message/109401 Thanks, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typed callable properties
Hi all,
śr., 22 kwi 2020 o 16:29 Dan Ackroyd napisał(a):
> On Tue, 21 Apr 2020 at 14:08, moliata wrote:
> >
>
> > I wanted to ignite a friendly discussion whether
> > PHP should allow typed callable properties.
>
> IMO no.
>
>
I agree, a callable brings as much information as a resource type - you
know the type
but are unable to use it without additional information.
> Trying to fix the problems with callables would be a huge amount of
> work, and not actually give that much benefit. Even just documenting
> the problems with callables* is a non-trivial amount of work, and I
> suspect there are many horrors lurking with the SPL code related to
> them.
>
> > I believe we should look into...
>
> I'm pretty sure that choosing a different problem to solve that:
>
> * would be easier to solve.
> * provide more benefit in the long term.
> * not require breaking a lot of userland + internal code immediately,
> but instead allow for migration over a longer period.
>
I was pinged by Dan with typedef topic nearly 3 weeks ago and then started
thinking of the way to define callable types with some initial
implementation.
I chose pattern known from other languages like C# where there are types
known as delegates.
And so far got to the last line of snippet below where I have to figure out
some clever type checking with closure:
delegate Reducer (?int $sum, int $item = 0): int;
class Foo implements Reducer {
public function __invoke(?int $sum, int $item = 0): int {
return ($sum ?? 0) + $item;
}
}
function reduce(Reducer $reducer) {
var_dump($reducer(0, 5));
}
reduce(new Foo());
reduce(fn(?int $sum, int $item = 0): int => 8);
The delegate declaration resolves to an interface with __invoke method
which therefore can be easily checked
when the invokable object passed and that information can be easily cached.
Probably it can be cached also for closures
and functions but didn't get so far with the implementation yet.
I was also asked why not a general use typedef which can be used to alias
any kind of type not only a callable.
But the reason why I chose delegates was that IMO typedef is more like an
aliasing mechanism, which means
all that is possible to be aliased should also be possible to be unaliased
and pasted in all type constraints used in
function/method parameters as well as class properties.
Meaning if we allow: typedef reducer = callable(?int $sum, int $item = 0):
int;
We should also allow: function(callable(?int $sum, int $item = 0): int
$reducer) {}
Which IMO looks too verbose and that's why I think a delegate might be a
good idea as a way to provide
callable types checking.
Any thoughts are highly appreciated!
Cheers,
Michał Brzuchalski
Re: [PHP-DEV] Typed callable properties
On Tue, 21 Apr 2020 at 14:08, moliata wrote: > > I wanted to ignite a friendly discussion whether > PHP should allow typed callable properties. IMO no. Trying to fix the problems with callables would be a huge amount of work, and not actually give that much benefit. Even just documenting the problems with callables* is a non-trivial amount of work, and I suspect there are many horrors lurking with the SPL code related to them. > I believe we should look into... I'm pretty sure that choosing a different problem to solve that: * would be easier to solve. * provide more benefit in the long term. * not require breaking a lot of userland + internal code immediately, but instead allow for migration over a longer period. My thoughts on adding 'function types' are here: https://github.com/Danack/FunctionTypes/blob/master/function_type_rfc.md There's still more than a couple of known problems that need to be worked through, as well as probably unknown problems lurking. As email is not a good format for carrying out discussions, if people want to take part in that discussion, doing it in that repo would be better imo. Assuming the problems remaining can be addressed, that would give us a more useful feature, and the existing 'callables' can be slowly deprecated and maybe removed from PHP in the distant future. cheers Dan Ack *[problems with callables] - https://wiki.php.net/rfc/consistent_callables -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] [DISCUSSION] Locale-independent float to string cast
Hi Guilliam, Thank you for the reminder, we certainly forgot to resolve that issue. After a quick investigation, it turned out that the %e and %E specifiers are already locale-insensitive, so we can leave them as-is. Furthermore, the definition of the %G specifier according to the documentation is "Like the g specifier but uses E and F", which is not true, since %G is always a locale-dependent format, while %F is not. That's why we think the way forward is to: - fix the documentation independently of this RFC - expose the %h and %H format specifiers which are "like the %g and %G specifiers, but really use %e/%E and %f/%F respectively". Nikita is currently working on adding support for these, so it's also not a dependency of the RFC. That's why the vote is still scheduled for tomorrow. Thanks, Máté (P.S: I've just seen that Nikita already wrote a similar answer)
Re: [PHP-DEV] Re: [RFC] [DISCUSSION] Locale-independent float to string cast
On Wed, Apr 22, 2020 at 10:53 AM Guilliam Xavier wrote: > On Tue, Apr 21, 2020 at 10:01 PM Máté Kocsis > wrote: > > > > That said, we'd like to open the vote on Thursday, unless serious > concerns > > arise > > in the meanwhile. > > > > Cheers, > > Máté > > Hi, thanks for the work, > > Shouldn't the RFC mention the open question of printf formats %e/%E > and %g/%G (and possible %H)? > I've started a separate thread to discuss related improvements to printf(). I believe the printf() improvements are useful independent of the outcome of this RFC, and don't need to block this RFC from going forward. Regards, Nikita
[PHP-DEV] printf() improvements
Hi internals,
I'd like to make two improvements to the printf() functionality exposed by
PHP (also affecting other variations like sprintf, vprintf, etc.) These
improvements are motivated by
https://wiki.php.net/rfc/locale_independent_float_to_string, which will
make float to string casts locale insensitive, but not change the behavior
of printf() specifiers.
The proposed improvements are:
1. Support for the %h and %H specifiers, which behave the same as %g and
%G, but are locale insensitive. These specifiers are already supported
internally in PHP (though %h goes by the name of %k for reasons that are
not relevant to userland) and is used for formatting floating-point numbers
where case-sensitivity is not desired, such as for var_export().
2. Support for * width and precision, in which case the width/precision is
provided as an argument to printf(). This is a feature of printf() in C.
The combination of these two features allows us to easily print floating
point numbers exactly as PHP would print them:
// Locale-sensitive using precision ini setting.
sprintf("%.*G", ini_get('precision'), $float);
// Locale-insensitive using serialize_precision ini setting.
sprintf("%.*H", ini_get('serialize_precision'), $float);
Notably, this also supports precision -1 (the default serialize_precision),
which will pick the shortest accurate representation of the float.
Without these features, it is actually quite hard to replicate PHP's exact
behavior. The best approximation I've found is to print with %G at multiple
precisions, pick out the shorted one and replace commas with dots on the
assumption that comma is the only locale-specific decimal separator. It
would be good to expose what PHP can already do directly.
Implementations for the two features are available at
https://github.com/php/php-src/pull/5432 and
https://github.com/php/php-src/pull/5436.
Regards,
Nikita
Re: [PHP-DEV] Re: [VOTE] Attributes v2 RFC Vote is open
On Tue, 21 Apr 2020 at 12:35, Benjamin Eberlei wrote: > The discussion on this RFC was 5 weeks and the syntax suggestions until > yesterday have all been suboptimal. > I appreciate the discussion period was 5 weeks, which was a generous allowance. It's also been an unusual 5+ weeks, with life and priorities disrupted for many people. Best wishes, Peter
Re: [PHP-DEV] Re: [RFC] [DISCUSSION] Locale-independent float to string cast
On Tue, Apr 21, 2020 at 10:01 PM Máté Kocsis wrote: > > That said, we'd like to open the vote on Thursday, unless serious concerns > arise > in the meanwhile. > > Cheers, > Máté Hi, thanks for the work, Shouldn't the RFC mention the open question of printf formats %e/%E and %g/%G (and possible %H)? -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function pipe operator
On Tue, Apr 21, 2020 at 4:44 PM Larry Garfield wrote: > > On Mon, Apr 20, 2020, at 11:20 PM, Stanislav Malyshev wrote: > > Just a small pedantry note - in a comparison section, the RFC compares > > this syntax to function composition. But this is not function > > composition. This is a syntax sugar for calling two functions one after > > another, not operator that produces a function. It sounds pedantic but > > it's rather important distinction - if |> is composition, than $foo |> > > $bar is a new callable provided $foo and $bar are callable (but no > > function is actually being called here!). If |> is call syntax, it's > > actually the result of calling $bar($foo). > > > > So comparing it to function composition is a bit confusing. Otherwise it > > looks OK to me, except the syntax for calling functions and methods is a > > bit awkward, but it's not the problem of this RFC I imagine. > > I'm not sure I follow. The only place composition is mentioned is in the F# > section, where it calls out specifically that we're implementing "pipe > forward" and *not* the composition operators ( >> ). Is that unclear? Actually it's also mentioned in the Haskell section, but as "function concatenation" (which adds to the confusion I guess). Speaking of Haskell, that reminded me of http://learnyouahaskell.com/a-fistful-of-monads#walk-the-line where the author defines a custom `-:` operator such that `x -: f` desugars to `f x` (equivalent to how `$x |> $f` would desugar to `$f($x)` with the RFC), which allows to write e.g. `xs -: sort -: reverse` instead of `reverse (sort xs)` or `(reverse . sort) xs`. -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
