Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52869
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=a5Vc/avK5szFEBs24gDLUEb7AL3ED7rnBaOqXLVKSUWbblXqP9oqm71I+hn6vP7q+e
         brLMRq78WbIHKUZiMI42yQybwXhmTc3sk1chITdSjJLTWqWMLQANMbmLkVWOObBQsoTU
         oamqEf/vhWbrrNHAnkZLv1nW1SWScQ1fXHvlw=
MIME-Version: 1.0
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B8060220A0A8@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>
Date: Fri, 3 Jun 2011 20:37:00 +0200
Message-ID: <BANLkTim4b=qcqEg5UPUoWzTHqerFbRzQQQ@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec54eeace0db19c04a4d30acf
Subject: Re: [PHP-DEV] RFC: Enum
From: dhaarbrink@gmail.com (Dennis Haarbrink)

--bcaec54eeace0db19c04a4d30acf
Content-Type: text/plain; charset=ISO-8859-1

2011/6/3 John Crenshaw <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

--bcaec54eeace0db19c04a4d30acf--