Clarification on the Enum language structure

15 years ago by Jarrod Nettles — view source — reply

unread

I was reading the RFC for the proposed enum language structure and was wondering if I could get some clarification on the implementation. Forgive me if this is in the patch or has been discussed already but based solely on what is written in the RFC I have some concerns.

http://wiki.php.net/rfc/enum

Nowhere in the RFC does it mention any of the enumerations as having a name, like a class would have a name. This seems like a critical point to me, for the following reasons.

· People will want multiple enumerations.

· Other programming languages allow for named enumerations.

· Parameters should be able to be type-hinted against enumerations just like they are classes. This will be a huge selling point, especially for framework developers and people who rely heavily on auto-complete from their IDEs.

· It will be difficult to namespace enumerations without a name, unless the intent is that there is a single global enum per namespace.

Also, enums inside of classes should be like any other property or method inside of a class in that you should able to mark them as public, private, or protected.

So, my proposed syntax would look something more like this.

namespace System\Logs
{
enum Levels{
DEBUG,
INFO,
WARNING,
ERROR
};
}

//or inside of a class

namespace System\Syntax
{
class Tokens{
public enum ControlStatements{
T_IF = 258,
T_ELSE,
T_WHILE,
T_DO
};

                            protected enum Operators{
                                            IS_IDENTICAL = 15,
                                            IS_NOT_IDENTICAL,
                                            IS_EQUAL,
                                            IS_NOT_EQUAL,
                                            IS_SMALLER,
                                            IS_SMALLER_OR_EQUAL
                            };
            }

}

Thanks!

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

15 years ago by Thomas Gutbier — view source — reply

unread

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

15 years ago by Martin Scotta — view source — reply

unread

On Mon, Feb 14, 2011 at 12:45 PM, Thomas Gutbier <
thomas.gutbier@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

--

+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 );