I just don't get why no type hinting, I thought that was one of the big points
so what are the purposes of the new enums? could you provide an example (a little snippet) of the usage of them? On Tue, Feb 22, 2011 at 11:15 AM, Ben Schmidt <mail_ben_schm...@yahoo.com.au > wrote: > Can't remember whether I answered this clearly. I don't think type hinting > is worth the implementation overhead (loss of efficiency) it would require. > > Ben. > > > Martin Scotta > > > On 23/02/11 1:11 AM, Jarrod Nettles wrote: > >> 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> >> >>
