I would argue that type hinting here is worth the overhead. Here’s my support for type hints:
1. They are optional – people truly concerned about squeezing every last drop of performance can opt to not use them and are probably using an accelerator anyway which will iron out such problems. 2. Programmer productivity should be just as large of a concern as performance. When it comes down to it the programmer is usually the most expensive resource in the software development lifecycle and performance issues can be solved with extra RAM or another server for a pittance. 3. Better IDE support. Having type hints right in the method makes it easier for the IDEs to adapt and become more intelligent which increase usability and programmer performance which increases the number of people willing to use PHP. 4. Better code readability. This is in line with point #2 – when I jump over to look at a method definition it will be 10x faster for me to see that particular parameter is an enum rather than having to search through the code to see that $cheese actually represents an enum of type Cheese. From: Martin Scotta [mailto:martinsco...@gmail.com] Sent: Tuesday, February 22, 2011 10:25 AM To: Ben Schmidt Cc: Jarrod Nettles; Thomas Gutbier; internals@lists.php.net; Stas Malyshev Subject: Re: [PHP-DEV] Re: Clarification on the Enum language structure 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<mailto: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<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<mailto: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> 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
