Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:52867 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 8595 invoked from network); 3 Jun 2011 17:51:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jun 2011 17:51:03 -0000 Authentication-Results: pb1.pair.com smtp.mail=johncrenshaw@priacta.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=johncrenshaw@priacta.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.238 as permitted sender) X-PHP-List-Original-Sender: johncrenshaw@priacta.com X-Host-Fingerprint: 64.95.72.238 mx1.myoutlookonline.com Received: from [64.95.72.238] ([64.95.72.238:6608] helo=mx1.myoutlookonline.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 24/48-08509-50F19ED4 for ; Fri, 03 Jun 2011 13:51:02 -0400 Received: from st22.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id A695178D3ED for ; Fri, 3 Jun 2011 13:50:59 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 0D09A78D382 for ; Fri, 3 Jun 2011 13:50:59 -0400 (EDT) Received: from MAILR001.mail.lan ([192.168.1.2]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Fri, 3 Jun 2011 13:50:03 -0400 To: "internals@lists.php.net" Date: Fri, 3 Jun 2011 13:50:52 -0400 Thread-Topic: [PHP-DEV] RFC: Enum Thread-Index: Acwh6YuiyazfQtzTSBu/trXEdKMtWwAKGNwg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [PHP-DEV] RFC: Enum From: johncrenshaw@priacta.com (John Crenshaw) 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.