Apologies - I wasn't suggesting we implement extension methods. I was simply changing my mind and agreeing with the earlier point that methods for enums can be useful.
What is everyone's opinion on enums as type hinted parameters? Being able to do... public function Killjoy(MyEnum $x) -----Original Message----- From: Ben Schmidt [mailto:mail_ben_schm...@yahoo.com.au] Sent: Friday, February 18, 2011 10:28 PM To: Jarrod Nettles Cc: Martin Scotta; Thomas Gutbier; internals@lists.php.net; Stas Malyshev Subject: Re: [PHP-DEV] Re: Clarification on the Enum language structure > I did some research on methods in enums and discovered that there is > some usefulness to the idea - I wouldn't go so far as to say that they > would be needed, but C#, for example, allows you to create extension > methods for enums and MSDN has a decent real-world example of its use. > > http://msdn.microsoft.com/en-us/library/bb383974.aspx It's a pretty big new concept that would need to be introduced if this was desired: extension methods. I think it's overkill myself. Something like this is fine: class Grade { enum { A_PLUS, A, B_PLUS, B, ..., FAIL, NOT_AVAILABLE, } public static function passing($grade) { return $grade>=self::D; } } $grade=Grade::B; echo Grade::passing($grade)?"passing":"not passing"; Having extension methods would also make enums much less efficient, as they would have to be stored as objects so their exact enum type could be determined at runtime if calling a method. I guess supporting type hinting properly also requires this, if that's desired, though. But I personally think something simple, much closer to the existing RFC, is fine. There isn't much benefit in type hinting--it could catch some programmer errors, but that's it--a small debugging tool. If it doesn't actually enable overloading (in the C++ sense) or something like that, it's not really an advantage. Regarding named enums, this could just be a shortcut for an enum in a class: enum Grade { A_PLUS, A, ... } is shorthand for class Grade { enum { A_PLUS, A, ... } } so you then do Grade::A etc.. You could disallow named enums in classes, or they could be named purely to make code self-documenting. > Enum type in the database is totally different because it's a > constraint, not an alias to some underlying piece of data like enums > in many programming languages. I think enforcing such constraint in > PHP would be quite complicated. No, I think enums in MySQL at least are true types, not just constraints--they are internally stored as integers and various optimisations are done with queries based on this. I agree strings as values do have the advantage of more robust (albeit less efficient) serialisation, including interacting with databases such as MySQL with enum types. So I think this would be worth allowing, but no more. So I would suggest having enum value allocation work like array indexes. If you don't supply a value, it uses the next unused integer. But you may alternatively supply an integer or a string. So, doing enum { FIRST, SECOND, THIRD, LAST = 'last' } would be much like doing $enum[]='FIRST'; $enum[]='SECOND'; $enum[]='THIRD'; $enum['last']='LAST'; in that 0, 1, 2 and 'last' are used. There's a few more cents from me. :-) 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
