Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52870
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.238 as permitted sender)
To: "internals@lists.php.net" <internals@lists.php.net>
Date: Fri, 3 Jun 2011 15:18:37 -0400
Thread-Topic: [PHP-DEV] RFC: Enum
Thread-Index: AcwiHSDQJ0TD0fXMTqKA0Hl5Wvc1JgAALuzQ
Message-ID: <A633CF2D7C7BED41B41F1E64F25507B8060220A0B3@MAILR001.mail.lan>
References: <BANLkTi=1XwcGhy8UP_9gtkxGX-PqDfwxVQ@mail.gmail.com>
	<BANLkTinCjPJTsKvUiFdXJQG4EB668Me_+g@mail.gmail.com>
	<BANLkTinemhsVsDM6eFzpB9vh6x-bbLdS_Q@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B8060220A0A8@MAILR001.mail.lan>
 <BANLkTim4b=qcqEg5UPUoWzTHqerFbRzQQQ@mail.gmail.com>
In-Reply-To: <BANLkTim4b=qcqEg5UPUoWzTHqerFbRzQQQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_A633CF2D7C7BED41B41F1E64F25507B8060220A0B3MAILR001maill_"
MIME-Version: 1.0
Subject: RE: [PHP-DEV] RFC: Enum
From: johncrenshaw@priacta.com (John Crenshaw)

--_000_A633CF2D7C7BED41B41F1E64F25507B8060220A0B3MAILR001maill_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



1.       Yeah, let me explain: A lot of times (at least in the patterns tha=
t lead to enum usage in C++) you need to be able to know what is in the enu=
m, 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 some=
thing, and often times you need to "enumerate" the enum. In C++, the only D=
RY 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 num=
ber of entries, so you can do something like for(int i =3D 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 th=
ink) is to be able to inspect the enum. Probably need to support count(enum=
type), 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. So=
metimes 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 inte=
gral, but doesn't actually act integral. The other problem with non-integra=
l enums is comparison, which users might expect to work by default. Unless =
this was implemented as a whole new type internally, comparison would be im=
possible. Implementing as a new type raises questions about implicit conver=
sion, so that probably won't work.


5.       This is heavily connected to the typesafety question. A simple pot=
ential PHP example that comes to mind would be the Zend_Log class. This cla=
ss has a list of priorities, which would make a whole lot of sense to put i=
n 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 argumen=
t, 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, especiall=
y in a derived class, so, I derive a new My_Log class, and want to extend t=
he enum with a couple of additional entries. (I actually worked with some c=
ode 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 whethe=
r 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@priact=
a.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 c=
oncerns that come to mind:

1. In C++ this often led to nasty needs such as a "LOG_LEVEL_COUNT" entry a=
t the end of the list of enums.
2. Sometimes devs want to add items in the middle of the list for code orga=
nization 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 s=
equential 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. Ad=
mittedly, this was sometimes more of a frustration than a help, but that wa=
s really just an implementation issue, not an inherent problem with enums a=
nd 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 auto=
matic numbering, and would complicate the inheritance question.

IMHO this should wait until we can address some of these items. Otherwise t=
he 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 pro=
posing enums
5: I have never felt the need for inheritance in enums. Do you have a use c=
ase for that?

I also think that enums should always be named.

--
Dennis Haarbrink



--_000_A633CF2D7C7BED41B41F1E64F25507B8060220A0B3MAILR001maill_--