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:dhaarbr...@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
<johncrens...@priacta.com<mailto:johncrens...@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
