RE: [PHP-DEV] RFC: Enum

1. Yeah, let me explain: A lot of times (at least in the patterns that lead to enum usage in C++) you need to be able to know what is in the enum, for example, to iterate a list that will have exactly the same number of entries as the enum or something. In other words, the enum represents something, and often times you need to "enumerate" the enum. In C++, the only DRY way to do this is to add a "*_COUNT" entry as the last enum, which will conveniently result in that entry getting assigned a value equal to the number of entries, so you can do something like for(int i = 0; i < FOO_COUNT; i++) {}. I can't say for sure that we will or won't run into this in PHP, but the nature of enums makes these sorts of patters likely. The fix (I think) is to be able to inspect the enum. Probably need to support count(enumtype), as well as something like enum_ids(enumtype), enum_values(enumtype), and enum_to_array(enumtype). 2. True, name as value is the only solution I see for that, but this would make the behavior radically different from the likely expectation. Sometimes it doesn't matter, but sometimes it will. I have some concern with something that LOOKS like an enum from other languages where enums are integral, but doesn't actually act integral. The other problem with non-integral enums is comparison, which users might expect to work by default. Unless this was implemented as a whole new type internally, comparison would be impossible. Implementing as a new type raises questions about implicit conversion, so that probably won't work. 5. This is heavily connected to the typesafety question. A simple potential PHP example that comes to mind would be the Zend_Log class. This class has a list of priorities, which would make a whole lot of sense to put in an enum. (Incidentally an "enum_to_array()" method would then allow this code to be cleaned up a bit). The log method accepts priority as an argument, so it would be sensible to give this a type hint. The catch is that the class is also designed to allow new priorities to be added later, especially in a derived class, so, I derive a new My_Log class, and want to extend the enum with a couple of additional entries. (I actually worked with some code almost exactly like this just a few days ago). The bottom line here is that enums become a hinderance to inheritance unless they can be extended. If an enum can't be extended, it is effectively final, regardless of whether that is actually helpful. John Crenshaw Priacta, Inc. From: Dennis Haarbrink [mailto:dhaarbrink@gmail.com] Sent: Friday, June 03, 2011 2:37 PM To: John Crenshaw Cc: internals@lists.php.net Subject: Re: [PHP-DEV] RFC: Enum 2011/6/3 John Crenshaw <johncrenshaw@priacta.com<mailto:johncrenshaw@priacta.com>> As much as I used enums in C++, I'm not sure that this is really the right tool here, and it often introduces more problems than it solves. Specific concerns that come to mind: 1. In C++ this often led to nasty needs such as a "LOG_LEVEL_COUNT" entry at the end of the list of enums. 2. Sometimes devs want to add items in the middle of the list for code organization purposes. This silently changes the values of the other constants and it isn't clear when that will or won't break stuff. 3. Better than half the time, enums seem to be a series of bit flags, not sequential numbers (in this case enum offers NO value over the current const lists). 4. The greatest value of enums in C++ is actually related to typesafety. Admittedly, this was sometimes more of a frustration than a help, but that was really just an implementation issue, not an inherent problem with enums and typesafety. 5. There is no clear path for extending the enums through inheritance. Allowing enums to be (optionally) named would open a clear path to address counts and hinting, but still doesn't address the problems inherent in automatic numbering, and would complicate the inheritance question. IMHO this should wait until we can address some of these items. Otherwise the feature is just a halfbaked not-so-short shorthand for constants. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 1. I'm not so sure what you mean with that statement 2. A very strong argument for using the name of the constant as the default value 3 and 4: The way I see it, type safety is the *only* valid argument for proposing enums 5: I have never felt the need for inheritance in enums. Do you have a use case for that? I also think that enums should always be named. -- Dennis Haarbrink