[RFC] enum SortDirection

Hi

That's a good idea, but I wouldn't introduce such class without some
usages at least.

I'd recommend considering immediately upgrading the proposed functions
to use SortDirection and redefine the constants in terms of the enum.

I.e. set const SORT_ASC = SortDirection::Ascending; - similar for others
like the SCANDIR_SORT_DESCENDING etc..

This is a reasonable BC break, which is also trivially fixed by simply
accepting int|SortDirection in existing functions.

A GitHub search for "language:PHP SORT_ASC" reveals that the existing
constants are used in userland code for custom purposes (e.g. within a
switch() statement). Redefining them to the enum would bring little
value, but unnecessarily break them. See also
https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum
for a precedent (specifically the Future Scope section there).

As suggested in the “Future Scope” of the featured RFC widening the core
functions to accept the enum and update the default value to the enum
case can just happen without an RFC, since this should not be observable
except by Reflection.

I want to avoid a situation of explicitly listing some of the
functions in the RFC, missing one and then later having a discussion of
whether or not it requires a follow-up RFC to also adjust that missed one.

Best regards
Tim Düsterhus

Hey Tim,

Hi

please consider this email as a formal request for comments on my modest proposal of adding a new enum SortDirection to PHP’s standard library.

I have made the full proposal available on the World Wide Web at:

https://wiki.php.net/rfc/sort_direction_enum

Yours sincerely
Tim Düsterhus

That's a good idea, but I wouldn't introduce such class without some usages at least.

I'd recommend considering immediately upgrading the proposed functions to use SortDirection and redefine the constants in terms of the enum.

I.e. set const SORT_ASC = SortDirection::Ascending; - similar for others like the SCANDIR_SORT_DESCENDING etc..

This is a reasonable BC break, which is also trivially fixed by simply accepting int|SortDirection in existing functions.

If its a BC break, it can't go into a 8.× for something that isn't necessary.

But I also don't see how accepting both int and this new enum for existing built-in functions is a BC break.

Changing the existing constants to something else is probably not a good idea, as other user functions or libraries might have reused them.

cheers
Derick