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.coll...@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.coll...@gmail.com> wrote: > On 19/04/2023 16:11, Garet Claborn 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. > > > On 23/04/2023 17:01, Robert Landers wrote: > > 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] >
