Clarification on the Enum language structure
| From: | Jarrod Nettles | Date: | Mon, 14 Feb 2011 13:51:11 +0000 |
| Subject: | Clarification on the Enum language structure | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-51446@lists.php.net to get a copy of this message | ||
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