Re: RFC: Enum

On 3 June 2011 08:26, Dennis Haarbrink <dhaarbrink@gmail.com> wrote: > So, to sum up: > - Do we really need enum level methods? > - Need to reach consensus on default values (strings vs auto inc. ints) > - RFC needs to be updated, explaining the type hinting of enums in method signatures I'm wondering if the enum storage would work like an array. The parallel ... array('YES', 'NO', 'MAYBE') vs. enum{YES, NO, MAYBE} In this example, all the keys of the array would be the same as the values of the enum array(0 => 'YES', 1 => 'NO', 2 => 'MAYBE') vs. enum(YES = 0, NO = 1, MAYBE = 2} In both cases, there is a name/value pairing. In both cases an unassigned key (for the array) or value (for the enum) is automatically determined. If a non sequential integer value is used ... array(2047 => 'E_ALL_PRE_5_2', 6143 => 'E_ALL_5_2', 30719 => 'E_ALL_5_3') vs enum{E_ALL_PRE_5_2 = 2047, E_ALL_5_2 = 6143, E_ALL_5_3 = 30719} then this still follows a recognisable pattern of key/value. If a non numeric key(array) or value(enum) is used, then I think the enum{} should follow the existing array() rules. If a mix is used, then there is already a well documented pattern of behaviour that I think should be followed. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea