Introduction - SuitespaceRnD

Hello,

For me, this is just a wrong way of using enums for the sake of opinionated
solution of specific problem.

Regards,
Dimitar

Hi

Hello PHP Internals,

I am Garet Claborn, CTO for Suitespace Inc
https://www.getsuiteux.com/, leading
up our R&D team. Just registered and my PHP Wiki username is:
suitespacernd

We use PHP extensively in our projects. Specifically I finally registered
as I have written up an RFC in response to this issue thread
https://github.com/php/php-src/issues/9208 on GitHub. While I am
notably
attached to said issue, I hope to provide useful feedback in general from
our case studies.

Feel free to reach out for whatever reason.

Cheers,
Garet Claborn

CTO, Suitespace Inc
garet@suiteux.com

Good luck with the RFC, I'm also quite interested in this feature so I'm
interested to see where it goes.
You might also want to explicitly ask for RFC karma so that you can create
a wiki page for the RFC, if you haven't done that already :)

Kind regards
Niels

--

To unsubscribe, visit: https://www.php.net/unsub.php

On Sun, Apr 23, 2023 at 1:23 PM Niels Dossche dossche.niels@gmail.com
wrote:

Hi

Good luck with the RFC, I'm also quite interested in this feature so I'm
interested to see where it goes.
You might also want to explicitly ask for RFC karma so that you can create
a wiki page for the RFC, if you haven't done that already :)

Kind regards
Niels

I am also interested to see where this goes, especially beyond the scope of
just enums.

Thanks for all the tips and feedback so far. I will try to respond to
clarify each so far.

On Sun, Apr 23, 2023 at 12:53 PM Rowan Tommins rowan.collins@gmail.com
wrote:

• If the aim is to allow array keys to be enum cases themselves (or
  objects in general), you'll likely need at least a partial
  implementation before taking it to a vote, as the impact on the rest of
  the engine, in terms of performance and complexity, will be a major
  deciding factor. You can still draft the RFC beforehand to judge the
  interest, however.

  • If the aim is to automatically cast the enum cases to ordinary strings
    or ints, expect some scepticism. I for one believe that it is an
    essential property of enums that Day::Monday == Month::January should be
    false, and it follows that array_key_exists(Day::Monday, [Month::January
    => true]) should be false as well.

First, we are indeed placing resources on getting this implementation on
our end (though any guidance is more than welcome as this is my first
attempt with the internals)

Niels Dossche also mentions we should request RFC karma.
I was unclear if I should wait until we have implemented further before
posting, however a simple text version exists already. Happy to do so now.

To your main point; I do agree with the general thrust of feedback on the
enum implementation given in that issue thread, which aligns more closely
to your second case. While the direction I presented in that issue
regarding the meaning and purpose of enumerations in programming and more
broadly did overwhelmingly outweigh dissent, there has been considerable
pushback about typing so far. However I would suggest that this can be
roadmapped into a win-win scenario rather than an A vs B scenario and the
RFC tries to reflect this.

Whereas object keys are a whole other can of worms at the moment, the RFC
makes recommendations which would align with both of these cases. For as
long as object keys do not exist, the value semantic would apply. Once
object keys do exist the only difference between the typesafe goal you are
looking for and our recommended implementation would be that

*Day::Monday == Month::January *would be true but
*Day::Monday === Month::January *would be false

Similarly with ArrayAccess, if we ever get more type resolution in the
context of keys this can be conveyed simply by strongly typing the function
parameters rather than current string or int types. As soon as PHP keys
accept object types, or even just a third enum type, this would immediately
enable the desirable

$current_month = $month[Day::Monday]; // Error
Assuming you indeed typed your getting such as offsetGet(Month $offset)

*Lynn *mentioned, " I am also interested to see where this goes,
especially beyond the scope of just enums."
This relates to the further roadmap concept I am referencing -- which is
not fully detailed but noted in the initial RFC, and the RFC is designed as
a useful milestone towards that roadmap.

We and many other PHP < 8 projects have usage patterns already established
with class constants which should rightly be seen as "hold ups" in
promoting the use of enums over the old way. By incentivizing such code to
make the switch to enums and providing a behavior which has no side effects
on existing code, other than removing an error, this is a benefit.

Finally because I am familiar with the case of labeling indices especially,
I am aware of methods that will help bridge the gap to eventual object
keys. Though out of scope for this first iteration that is a large part of
the purpose. If implemented, a follow-up RFC can go into more detail; but
the gist is: existing object key RFCs have discovered ways to implement
this for select types of objects but not the general case. With value
semantics implemented, and some glue code in userland, we have recovered
the ability to overload array mechanics further already to allow type
checks.

If this use pattern were further enabled - even the simple value semantics,
we can then use enums as aliases to type checking mechanics for object keys
purely in user land. From there it becomes a simple matter of closing the
gap until at least enums can be a third type of key which provides a type
safety proxy to related objects. This in turn could be further contracted
if full object keys become available - which is enabled by the use patterns
preexisting in userland.

Though I am working along this line of reasoning above to edit the need for
that debate out of the roadmap, I will reiterate my original reasoning for
favoring the second case, prioritizing value semantics.

First because we don't really have an option as long as key contexts such
as ArrayAccess only support int and string at present.

More strongly: Enumerations are constructs which span many disciplines for
which strong assertions can be made about their correlation to lists and
coverage of such lists. Even in cases where an enumeration's order does not
have a numeric definition, the ordinality still exists and may be exploited
in many ways. Enumeration as a word itself implies "to number" or count,
and as such has well-defined mathematical properties which relate to
natural numbers. There are categories of algorithms which rely on this and
cannot be implemented by reflection or other means. Specifically, many
constant time algorithms can take advantage of labeled indices and some
cannot be implemented without them.

All that said, after the various feedback so far the history I cared about
turns out to matter less than the simple fact that instances of an enum are
effectively userland symbols.

Example / TL:DR:
I may presently write $selected = $list[ $x ];
Whether $x=0 or $x='apple', I am not required to use $list[ $x->value ]
Symbols map to their value without requiring ->value, but retain
typesafety in many contexts. Ultimately we do want to get there but start
at values.

Thanks again for all the feedback,
Garet Claborn

Also, Robert Landers in response to your userland code. There are cases
where it is possible to get very close semantics

On Sun, Apr 23, 2023 at 12:53 PM Rowan Tommins rowan.collins@gmail.com
wrote:

Specifically I finally registered
as I have written up an RFC in response to this issue thread
https://github.com/php/php-src/issues/9208 on GitHub.

Welcome, and in case you haven't found it already, here's the guide to
the RFC process: https://wiki.php.net/rfc/howto

I'll wait with interest to see the RFC, but would note two things:

• If the aim is to allow array keys to be enum cases themselves (or
  objects in general), you'll likely need at least a partial
  implementation before taking it to a vote, as the impact on the rest of
  the engine, in terms of performance and complexity, will be a major
  deciding factor. You can still draft the RFC beforehand to judge the
  interest, however.

• If the aim is to automatically cast the enum cases to ordinary strings
  or ints, expect some scepticism. I for one believe that it is an
  essential property of enums that Day::Monday == Month::January should be
  false, and it follows that array_key_exists(Day::Monday, [Month::January
  => true]) should be false as well.

Even if it
has to be something 'ugly' to keep people from using that itself as a
value (similar to how js symbol types work -- a one-way cast).

As far as I understand, Symbols in JS are entirely their own type, and
the definition of objects directly allows property keys to be either a
String or a Symbol; so it is equivalent to PHP allowing enum cases, but
not other objects, to be array keys.

Properties are identified using key values. A property key value is
either an ECMAScript String value or a Symbol value. All String and
Symbol values, including the empty String, are valid as property keys.

https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-object-type

Regards,

--
Rowan Tommins
[IMSoP]