You're right, my example was broken with regard to type hinting. Should
have been more like:

abstract class Element {
     enum Type {
        Hydrogen,
        Argon,
        Iron
     }
     public static function weight(Element::Type $e) {
        ...
     }
     ...
}
function print_element(Element::Type $e) {
     echo Element::weight($e), PHP_EOL,
      Element::density($e), PHP_EOL,
      Element::protons($e), PHP_EOL,
      Element::neutrons($e);
}
print_element(Element::Hydrogen);
print_element(Element::Argon);
print_element(Element::Iron);

which I agree is quite a bit more ugly.

So maybe member methods are useful after all. However, I think they need
to be implemented differently to the 'extension method' mechanism of C#.
In PHP, we could simply require them to be static methods, and set $this
to the enum constant value (strongly typed) when they are called.

So I think all your recommendations are good, as long as.

- We take care to implement it efficiently, so enum comparisons etc. are
  pointer comparisons, not string or other comparisons.
- We are careful to restrict enum member functions appropriately so
  enums don't turn into full-blown classes.

Ben.



On 24/02/11 2:34 AM, Jarrod Nettles wrote:
I don't think that your implementation will work as it would require
an entire re-imagining of type hinting and/or of classes. In your
example, any method that type hinted against "Element" would be
expecting an instance of the abstract class, "Element". There's no way
to differentiate between the two.

Another thing to consider: suppose another class extends your abstract
class "Element" and defines its own enum? Which takes precedence? Do
the two merge, overwrite, etc? I think that would end up causing more
problems than it's worth.

Based on our current discussion and recommendations, here's how I
would say we define a PHP enum:

1. An enumeration has a name, whether outside a class or inside a class.
2. The names of the constants are strings.
3. Values can be integrals or strings. No complex types or arrays.
4. Can be namespaced like any class, function, or interface.
5. Can have member methods, must be declared as static since an enum cannot be 
instantiated.
6. Parameters can be type hinted against enums. For consistency, in the event 
of invalid arguments we should probably stay in line with what happens when a 
type hint for a class is broken.



-----Original Message-----
From: Ben Schmidt [mailto:mail_ben_schm...@yahoo.com.au]
Sent: Wednesday, February 23, 2011 9:01 AM
To: Martin Scotta
Cc: Alexey Zakhlestin; Stas Malyshev; Jarrod Nettles; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Clarification on the Enum language structure

I think this is good enough:

abstract class Element {
     enum {
        Hydrogen,
        Argon,
        Iron
     }
     public static function weight(Element $e) {
        ...
     }
     ...
}
function print_element(Element $e) {
     echo Element::weight($e), PHP_EOL,
      Element::density($e), PHP_EOL,
      Element::protons($e), PHP_EOL,
      Element::neutrons($e);
}
print_element(Element::Hydrogen);
print_element(Element::Argon);
print_element(Element::Iron);

Ben.



<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>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to