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:
