On Thu, Feb 17, 2011 at 3:01 PM, Jarrod Nettles <jnett...@inccrra.org>wrote:
> An enum is not a class. totally agree. an enum is a family of related constant values. > It has no methods or properties and is not something that you instantiate. > partially agree, you cannot instantiate nor destruct a constant. it's a value that does not change over time, but why can't it be an immutable object? > > Also, I feel like it should be restricted to integral types only, and > defaults to a zero-based incrementing integer. This is more in line with > other programming languages that already implement enums and will present > "expected behavior" for people moving over to PHP. > for me that's a plain old interpretation of constants. constant values were only integer values because of their implementation, nowadays they could be anything you want, int, float, string and even objects. enum MyEnum { A, B, C; function test() { return true; } } $value = MyEnum:B; if ( $value->test() ) { echo ' what is wrong with this ? '; } > > Enums shouldn't be an overly complicated construct - it should be, quite > simply, a namespaced, named constant with an integral value that promotes > code readability and reuse. > > Also, something I forgot in support of my argument for named and namespaced > enums.... > > People are likely to keep enums in separate files (following the rule of > one "construct" per file) and thus will need to support autoloading. The > only way to achieve this will be by passing a fully qualified name into the > registered autoloaders. > > /Framework/Web/Mvc/HttpVerbsEnum > > > -----Original Message----- > From: Martin Scotta [mailto:martinsco...@gmail.com] > Sent: Monday, February 14, 2011 11:27 AM > To: Thomas Gutbier > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Re: Clarification on the Enum language structure > > On Mon, Feb 14, 2011 at 12:45 PM, Thomas Gutbier < > thomas.gutb...@anthrotec.de> wrote: > > > Jarrod Nettles wrote: > > > >> So, my proposed syntax would look something more like this. > >> > > > > I think also and was wondering about the current rfc for a few weeks. > > Im not a core developer but I want to outline what i would expect as > > php framework developer. > > > > > > namespace System\Logs > >> { > >> enum Levels{ > >> DEBUG, > >> INFO, > >> WARNING, > >> ERROR > >> }; > >> } > >> > > > > Yes, after that I would expect a new type "Levels" > > and the possibility to do something like this: > > > > $log = new Levels; > > $log = WARNING; > > or > > $log = new Levels(WARNING); > > > > Like the current rfc i think, therefore we need the corresponding > > constants to be defined by defining the Levels type. > > > > Furthermore we should have the appropriate type hints for > > function/method calls. > > > > Assuming, we have a method like this > > > > public function setLogLevel (Levels $logLevel) > > { > > $this->logLevel = $logLevel; > > } > > > > i would like to call them by delivering $log as a parameter > > > > $someLogginObject->setLogLevel($log) > > > > and get an error in the case the type of $log is not Levels. > > > > What do you think about a viable approach to > > implement a enum language structure. > > > > The current rfc seams not very useful for me. > > > > Thanks! > > > > Thomas Gutbier > > Web Developer > > Hannover, Germany > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > +1 with this! > > but I don't understand is why the elements have to be scalar values. > If the "enum" is a class... > > enum Token { > > IF ( array('if', T_IF)), > FOR ( array('for', T_IF)), > WHILE( array('while', T_IF)), > PLUS ( '+' ), > MINUS ( '-' ); > > private $symbol; > private $value; > > function __construct($token) { > if (is_array($token)) { > $this->value = $token[0]; > $this->symbol = $token[0]; > return > } > $this->value = $this->symbol = $token; > } > > function getSymbol() { return $this->symbol; } > function getValue() { return $this->value; } > } > > > function test(Token $t) { > echo $t->getSymbol(), PHP_EOL, $t->getValue(), PHP_EOL; > } > > test( Token::IF ); > test( Token::PLUS ); > <html> > <body> > Jarrod Nettles Application Developer - Technology INCCRRA p 309.829.5327 - > f 309.828.1808 This e-mail message may contain privileged or confidential > information. If you are not the intended recipient, you may not disclose, > use, disseminate, distribute, copy > or rely upon this message or attachment in any way. If you received this > e-mail message in error, please return by forwarding the message and its > attachments to the sender. INCCRRA does not accept liability for any errors, > omissions, corruption or virus in > the contents of this message or any attachments that arises as a result of > e-mail transmission. Please consider your environmental responsibility > before printing this e-mail > </body> > </html> >