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 > > Background: The RFC https://wiki.php.net/rfc/any_all_on_iterable proposes > adding only two functions, > but more functionality acting on iterables (array|Traversable) may be added > in the future, > making it important to get feedback what people feel the best choice of > naming pattern would be > to avoid inconsistency or name changes later on. > (Many alternatives were suggested in the initial RFC announcement - > https://externals.io/message/111756)
> From Nikita Popov, > Using just the SPL namespace (that is, SPL\any) makes the SPL namespace a > dumping ground for everything, as you said. Once you introduce an > additional meaningful namespace in the form of SPL\iterable\any, you are > better off either dropping the SPL part and arriving at iterable\any, or > replacing SPL with something more sensible and arriving at PHP\iterable\any. > > TBH I think Tyson's original approach of not including namespaces as a > possibility was the right one. We clearly still don't have any consensus on > how to structure namespaces in PHP extensions and it doesn't seem like a > question that should be resolved as a footnote of another RFC. There have > been multiple RFCs one the topic, and none of them reached anything even > approaching a consensus. I'm planning to revise https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace due to feedback that the proposed namespace choices differs from prior proposals such as https://wiki.php.net/rfc/php_namespace_policy and perceived interest in options such as PHP\SubNS\ Although my original intent was to add `*any*()` and `*all*()` to the language rather than work on PHP namespace policy, I still feel obligated to gather feedback for this specific use case since this discussion may come up in future RFCs adding new categories of functionality. There'd be an unmanageable amount of options to vote among if I poll on the combination of namespace and name, which is even more unpleasant since we currently don't have a widget dedicated to STV(Single Transferrable Vote) polls (that I know of), just forms that must be submitted individually. (e.g. is X\iter\any_value() preferable over X\iterable_any()) - Additionally, we haven't yet determined if there's a consensus on namespaces. My plan is to start a different STV straw poll, on - no namespace: iterable_any()/iterable_all() - iter\ (conflicts with nikic/iter but was also suggested by Nikita) - iterable\ (see below note) - PHP\ (This deliberately uses uppercase, see https://www.php.net/manual/en/language.namespaces.rationale.php) - PHP\iter\ - PHP\iterable\ (see below note) - Ext\Spl\, as suggested in https://wiki.php.net/rfc/php_namespace_policy - Spl\ - Spl\iter\ - Spl\iterable\ (see below note) And if there's a clear preference for a namespace, start a second STV straw poll between iterable_any(), NS\any(), NS\any_value, NS\iterable_any(), for the preferred namespace. I've also realized that `use prefix\iterable` would be mildly inconvenient for users of PHP and for tooling for PHP, but still include it as an option because it's manageable and the non-namespaced prefix `iterable_` was preferred in the previous poll. ``` php > namespace W { echo iterable::class; } W\iterable php > namespace X { use iterable; } Fatal error: Cannot use iterable as iterable because 'iterable' is a special class name in php shell code on line 1 php > namespace X { use iterable\any; /* using individual functions works */ } php > namespace Y { use PHP\iterable; function foo(iterable $x) {}} Fatal error: Cannot use PHP\iterable as iterable because 'iterable' is a special class name in php shell code on line 1 php > namespace Z { use PHP\iterable as iter; } php > namespace iterable { echo "can be polyfilled\n"; } can be polyfilled ``` - I don't personally see the need for having "Cannot use iterable as iterable" be a fatal error (especially since that token can be used in namespaces), but I'd really prefer avoiding iterable entirely to avoid special case namespaces in PHP's standard library. It could be argued that the type is in some sense used by any namespace so it's permissible to silently allow it. `namespace W { echo iterable::class; }` is `W\iterable`, so this isn't technically true. It'd also be inconsistent to allow `use iterable;` but not `use int;`, but making that change is a separate proposal. - `use PHP\iterable` would cause some inconvenience, but code can work around it with `use PHP\iterable as iter;`. This may cause edge cases in IDEs, automatically generated code changes, etc. - The edge cases involved in `iterable` are why I propose iter\ as an additional voting option. Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
