You are missing something. Using this new feature would be voluntarily (it is optional like type hints are already).
If you want to code the old way and you don't want to force coders to use your functions correctly, you could leave out typehints an check the parameters manually. But if you want to write strict API's, that accept only a special type of parameters (and type hinted parameters were introduced to be able to do this) you would still be able to accept more than one type of parameters (without this additional feature you are not able to do it right now). You do not use type hints in your functions, thats why you don't understand the need of overloding methods by parameter siganture. If you would understand the need of type hints for robust applications you would understand the need of overloading typehinted methods. Btw: You could call foo((integer) $x); to ensure the right method is called. Like I already said, this feature is only require for people writing complex web applications, offering api's to 3rdparty coders that are very strict. If you are coding a project within your company you can rely on the fact, that programmers should know how to use your methods, but a 3rdparty coder who extends the functionality of your product doesn't know and there should be no chance to crash the application. -----Ursprüngliche Nachricht----- Von: Christian Schneider [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 14. Oktober 2007 14:27 An: Marcus Boerger Cc: internals@lists.php.net Betreff: Re: AW: [PHP-DEV] Method overloading by method signature Marcus Boerger wrote: > If you have such a patch you should definitively post it here so that we > can hve a look. Most interesting to us is however the oerformance impact. As > that was the main reason to go any further than adding return type hints. Am I the only here who thinks that performance is not the major issue with this approach? Method signatures lead to a different style of programming I personally wouldn't want to encourage in PHP. I'm expecting some kind of "if you don't like it don't use it" answer but I wouldn't want to bloat the language for such a feature anyway. Example: It's too easy for someone to think it's a good idea to change function foo($x) { ... } to something like function foo(string $x) { ... } function foo(int $x) { ... } but this can lead to very subtle bugs as automatic type conversion can trick you into passing something different than you thought and hence could lead you to do foo(strval($x)); all over the place to not get any surprises. A Bad Thing(TM) IMHO. Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
