On Thu, Feb 17, 2011 at 3:01 PM, Jarrod Nettles <[email protected]>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:[email protected]]
> Sent: Monday, February 14, 2011 11:27 AM
> To: Thomas Gutbier
> Cc: [email protected]
> Subject: Re: [PHP-DEV] Re: Clarification on the Enum language structure
>
> On Mon, Feb 14, 2011 at 12:45 PM, Thomas Gutbier <
> [email protected]> 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>
>
