Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays
> On Dec 19, 2020, at 19:43, tyson andre > wrote: > > It can be useful to verify that the assumption that array keys are > consecutive integers is correct, both for data that is being passed > into a module or for validating data before returning it from a > module. However, because it's currently inconvenient to do that, this > has rarely been done in my experience. I think there are some places where `is_list()` could be unintuitive to those who don’t understand some of the idiosyncrasies of PHP. For example, with $a = ['foo', 'bar', 'baz’]; `is_list()` will return `true`, but if you run `$a` through `asort()`, `is_list()` will return `false` because the keys are no longer consecutive integers, but is there any doubt this is still a list? Maybe in a pure sense, it’s not, but I think this could be confusing. But now, if we do $b = array_merge($a, ['qux', 'quux']); `$b` is now back to being a list, so `is_list($b)` returns `true`. While I understand the convenience `is_list()` provides--I myself have implemented the opposite of this numerous times (e.g., `is_dict()`)--it comes close to implying a data type that PHP doesn’t have, and I think this could give a false sense of type-safety-ness when using this function to check whether something is a 0-indexed array. Cheers, Ben signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] Re: Straw poll: Naming for `*any()` and `*all()` on iterables
Hi Mark Randall, > These functions make sense. However I think we need to give renewed > consideration to: > > $itr->all(); > $itr->some(...); That wouldn't help for arrays, which would be the most common use case - I don't remember seeing an RFC for https://github.com/nikic/scalar_objects and that is a much larger language change. This also wouldn't help if I wanted something that could be used on any Traversable. Currently, there's no support for default methods for interfaces such as Iterator/IteratorAggregate - I think I saw some discussion of that. (e.g. to check for any()/all() on generators, user-defined classes, etc) Backwards compatibility of method signatures with the same names that were written before default methods were added would be a concern, though. (https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html) Regards, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Straw poll: Naming for `*any()` and `*all()` on iterables
On 19/12/2020 20:24, tyson andre wrote: Hi internals, I've created a straw poll for the naming pattern to use for `*any()` and `*all()` on iterables. https://wiki.php.net/rfc/any_all_on_iterable_straw_poll These functions make sense. However I think we need to give renewed consideration to: $itr->all(); $itr->some(...); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Configurable callback to dump results of expressions in `php -a`
Hi internals, I've created a new RFC https://wiki.php.net/rfc/readline_interactive_shell_result_function adding a way to configure a callback to be called to dump the value of single-expression statements from `php -a` (and an ini setting that can be disabled to prevent that callback from being called). Many REPLs (Read-Eval-Print Loops) for other programming languages that I'm familiar with print a (possibly truncated) representation of the result of expressions, but PHP doesn't. It would be useful to allow users to extend the functionality of the default interactive php shell (php -a), possibly with auto_prepend_file or through use of command wrappers/aliases, or after loading the shell. Prior to this RFC, there was no way to extend the interactive php shell in this way. (I've seen https://github.com/bobthecow/psysh mentioned as an alternative for php -a while investigating this, but that's a shell written from scratch, and doesn't have some functionality from php -a such as tolerance of fatal errors) Because PHP's interactive shell is written in C, adding new features or bug fixes is inconvenient - it would require a lot of time getting familiar with C programming, PHP's internals and memory management, and with PHP's internal C ast representation. It would be easier and more accessible to extend PHP's interactive shell through code written in PHP rather than code written in C. This was among the proposed enhancements I brought up in https://externals.io/message/111073 . An earlier version of the implementation was also created months ago - https://github.com/php/php-src/pull/5962 Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays
I appreciate this idea as I ran into the same issue with one of my libraries when I wrote similar rules. Granted, I’m using “array” and “dictionary” not “list” as both terms seem common to the community and used to distinguish the two. But that’s semantics, which I’m sure will be discussed at a later date; short version: is_array and is_dict(ionary). 1. Sequential using int starting at 0 2. Non-sequential using strings for all keys 3. Standard PHP array with potential mixed keys. Cheers, Josh > On Dec 20, 2020, at 2:09 PM, tyson andre wrote: > > Hi Larry Garfield, > >> Well, since I'm quoted... :-) >> >> I'm fine with this, but have one question and one correction: >> >> * If we do eventually end up with list/vec types, would the naming here >> conflict at all? Or would it cause confusion and name collision? (Insert >> name bikeshedding here.) >> >> * The last quote, from me, has a small error. The last sentence shouldn't >> be a bullet point but its own paragraph, after the list is complete. > > Yes, there's definitely the potential for naming conflicts if the type is > called `list` > but not if it's called `vec`/`vector`/`varray` similar to > https://docs.hhvm.com/hack/built-in-types/arrays - I'd prefer the latter if > there was a viable implementation. > I should note that in the discussion section. > > If the type is named `list` instead of `vector` and ends up incompatible with > arrays, > there'd need to be an `is_list_type($val)` or `$val is list` > or some other new type check with a less preferable name. > If it's compatible with arrays/lists > (e.g. only checked during property assignment, passing in arguments, and > returning values), then it wouldn't be an issue. > > - is_array_list() or is_array_and_list() or is_values_array() would avoid > some of that ambiguity but would be much more verbose > > Providing objects with APIs similar to the external PECL > https://www.php.net/manual/en/class.ds-vector.php and the SPL may be easier > to adopt because it can be polyfilled, > but there's the drawback that there aren't the memory savings from > copy-on-write and that there's the performance overhead of method calls to > offsetGet(), etc. > > I'd expect the addition of a separate/incompatible vec type to be a massive > undertaking, and possibly unpopular if it splits the language. > In Hack/HHVM, it was practical for users to adopt because HHVM is bundled > with a typechecker that checks that the uses > are correct at compile time - because PHP has no bundled type checker, a new > type would potentially cause a lot of unintuitive behaviors. > > I fixed the formatting of the quote. > > -- Tyson > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays
Hi Larry Garfield, > Well, since I'm quoted... :-) > > I'm fine with this, but have one question and one correction: > > * If we do eventually end up with list/vec types, would the naming here > conflict at all? Or would it cause confusion and name collision? (Insert > name bikeshedding here.) > > * The last quote, from me, has a small error. The last sentence shouldn't be > a bullet point but its own paragraph, after the list is complete. Yes, there's definitely the potential for naming conflicts if the type is called `list` but not if it's called `vec`/`vector`/`varray` similar to https://docs.hhvm.com/hack/built-in-types/arrays - I'd prefer the latter if there was a viable implementation. I should note that in the discussion section. If the type is named `list` instead of `vector` and ends up incompatible with arrays, there'd need to be an `is_list_type($val)` or `$val is list` or some other new type check with a less preferable name. If it's compatible with arrays/lists (e.g. only checked during property assignment, passing in arguments, and returning values), then it wouldn't be an issue. - is_array_list() or is_array_and_list() or is_values_array() would avoid some of that ambiguity but would be much more verbose Providing objects with APIs similar to the external PECL https://www.php.net/manual/en/class.ds-vector.php and the SPL may be easier to adopt because it can be polyfilled, but there's the drawback that there aren't the memory savings from copy-on-write and that there's the performance overhead of method calls to offsetGet(), etc. I'd expect the addition of a separate/incompatible vec type to be a massive undertaking, and possibly unpopular if it splits the language. In Hack/HHVM, it was practical for users to adopt because HHVM is bundled with a typechecker that checks that the uses are correct at compile time - because PHP has no bundled type checker, a new type would potentially cause a lot of unintuitive behaviors. I fixed the formatting of the quote. -- Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays
On Sat, Dec 19, 2020, at 7:43 PM, tyson andre wrote:
> Hi internals,
>
> I've created the RFC https://wiki.php.net/rfc/is_list
>
> This adds a new function `is_list(mixed $value): bool` that will return
> true
> if the type of $value is array and the array keys are `0 ..
> count($value)-1` in that order.
>
> It's well-known that PHP's `array` data type is rare among programming
> languages
> in that it supports both integer and string keys
> and that iteration order is important and guaranteed.
> (it is used for overlapping use cases - in many other languages, both
> vectors/lists/arrays and hash maps are available)
>
> While it is possible to efficiently check that something is an array,
> that array may still have string keys, not start from 0, have missing
> array offsets,
> or contain out of order keys.
>
> It can be useful to verify that the assumption that array keys are
> consecutive integers is correct,
> both for data that is being passed into a module or for validating data
> before returning it from a module.
> However, because it's currently inconvenient to do that, this has
> rarely been done in my experience.
>
> In performance-sensitive serializers or data encoders, it may also be
> useful to have an efficient check to distinguish lists from associative
> arrays.
> For example, json_encode does this when deciding to serialize a value
> as [0, 1, 2] instead of {“0”:0,“2”:1,“1”:1}
> for arrays depending on the key orders.
>
> Prior email threads/PRs have had others indicate interest in the
> ability to efficiently check
> if a PHP `array` has sequential ordered keys starting from 0
>
> https://externals.io/message/109760 “Any interest in a list type?”
> https://externals.io/message/111744 “Request for couple memory
> optimized array improvements”
> Implementation: https://github.com/php/php-src/pull/6070 (some
> discussion is in the linked PR it was based on)
>
> Thanks,
> - Tyson
Well, since I'm quoted... :-)
I'm fine with this, but have one question and one correction:
* If we do eventually end up with list/vec types, would the naming here
conflict at all? Or would it cause confusion and name collision? (Insert name
bikeshedding here.)
* The last quote, from me, has a small error. The last sentence shouldn't be a
bullet point but its own paragraph, after the list is complete.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Improving PRNG implementation.
On Sun, Dec 20, 2020 at 6:45 AM zeriyoshi wrote: > Thanks cmb. I have created a first draft of an RFC. I think I've covered > all the necessary requirements, but I'd like to know if there are any > problems. > https://wiki.php.net/rfc/object_scope_prng A few IMHO comments: * Namespaces are controversial. There were multiple discussions and RFCs about introducing them for new functionality but nothing came out of it. Still probably worth adding an option for \PHP\PRNG to the vote, or something like that. * The "Which set of PRNGs should be provided as standard?" vote seems vague to me. Are you proposing to add only one algorithm? Why? Also, the adding just interfaces option makes no sense because there's Composer for things that don't require a C implementation. * "One possible solution is to implement the PRNG in pure PHP. There is actually a userland library [1], but it is not fast enough for PHP at the moment. (However, this may be improved by JIT)" - this definitely needs a comparison because implementation in C is only needed for performance reasons. * Method names: you don't need to emulate the conventions from non-OOP code, e.g. string_shuffle() --> strShuffle and array_rand() --> arrayRand(). Use a more naturally readable convention like shuffleString(). * The return value in "function shuffle(array &$array): bool" means that if something goes wrong, callers will have no idea what it is. Just throw an exception. * If the classes are namespaced, don't prefix their names, e.g. PRNGInterface --> RandomGenerator (yay, so many opportunities for bikeshedding!) * Perhaps it's worth mentioning other languages using this pattern, e.g. Java[1] and C#[2]. * Do you have evidence of widespread demand for this functionality? Usage statistics for the userland implementation you mentioned[3] don't look that hot. -- [1] https://docs.oracle.com/javase/8/docs/api/java/util/Random.html [2] https://docs.microsoft.com/en-us/dotnet/api/system.random?view=net-5.0 [3] https://packagist.org/packages/savvot/random
[PHP-DEV] Re: Improving PRNG implementation.
On 20.12.2020 at 04:45, zeriyoshi wrote: > On 19.12.2020 at 11:26, Christoph M. Becker wrote: > >> RFC karma granted. Best of luck with the RFC! :) > > Thanks cmb. I have created a first draft of an RFC. I think I've covered > all the necessary requirements, but I'd like to know if there are any > problems. > https://wiki.php.net/rfc/object_scope_prng > > As for the second suggestion, I saw that the RFC was tagged on GH. This is > not a new feature and does not seem to be a bc break. Do we still need an > RFC in this case? > https://github.com/php/php-src/pull/6520 Sorry, my bad. I thought that PR was an implementation of the RFC. I've removed the RFC label now. Christoph > Regards, > Go Kudo > > 2020年12月19日(土) 20:26 Christoph M. Becker : > >> On 19.12.2020 at 07:33, zeriyoshi wrote: >> >>> On Wed, Dec 16, 2020 at 8:46 AM zeriyoshi wrote: >>> >>> I have created an account on the PHP.net wiki to create an RFC about >> this. >>> Can you grant me editing privileges? >> >> RFC karma granted. Best of luck with the RFC! :) >> >> Christoph >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short-match
On Sat, 19 Dec 2020, 02:48 Larry Garfield, wrote:
> On Fri, Dec 18, 2020, at 1:40 PM, Olle Härstedt wrote:
> > What about matching on a variable's type?
> >
> > ```
> > match {
> > $var: string => "is a string"
> > $var: array => "something else"
> > }
> > ```
> >
> > This could be used with flow-sensitive typing, e.g. assume the type of
> $var
> > being string in the string block. Psalm works like this for
> if-statements.
> > Also consider the case with generics.
> >
> > Compare with generalised algebraic data types in FP (GADT).
> >
> > Olle
>
> That would be more along the lines of the pattern matching RFC that Ilija
> and I have been kicking around for post-enums:
> https://wiki.php.net/rfc/pattern-matching
>
> That's still in the "it would be cool if" stage only, and is IMO off topic
> from the abbreviation effort in this RFC.
>
> --Larry Garfield
>
Very cool. Thanks for the link. Looking forward to further implementations!
Olle
--
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
