Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Method overloading by method signature »

Method overloading by method signature

php.internals

Hans Moog

18 years ago
Will method overloading by method signature be implemented in php6 or even php 5.3? Example: <?php namespace xyz; import core::TestClass; class Test extends TestClass { public string function test(integer $int) { return "Hi"; } public integer function test(string $string, integer $int) { return $int; } } ?> I think this would be a very big advantage and would help developers to write better code.

Alexey Zakhlestin

18 years ago
Hans, such overloading would be incompatible with php's dynamic nature As far as I remember, even type-hinting for basic-types (strings, integers) was rejected On 10/13/07, Hans Moog <hans.moog@mkj-computing.de> wrote:
> Will method overloading by method signature be implemented in php6 or > even php 5.3? > > > > Example: > > <?php > > namespace xyz; > > > > import core::TestClass; > > > > class Test extends TestClass { > > public string function test(integer $int) { > > return "Hi"; > } > > > > public integer function test(string $string, integer $int) { > > return $int; > } > } > > ?> > > > > I think this would be a very big advantage and would help developers to > write better code. > >
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Hans Moog

18 years ago
Why would it be incompatible with php's dynamic nature? (I already heard many people saying "that this is not the php way") But why ? Don't you like it or do you think it is just not possible to be implemented in php? I could provide a patch that makes it possible (even with complete visibility and inheritance rules). We already use it and it saves us a lot of code. I think it is better than the '$x = "defaultValue"' kind of way to accept different count and types of parameters because it is MUCH more expressive and intuitive. It wouldn't even break backward compatibility beause it is just "syntactical sugar" to checking the variable types manually and then dispatching to the right behaviour. -----Ursprüngliche Nachricht----- Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] Gesendet: Samstag, 13. Oktober 2007 22:22 An: Hans Moog Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] Method overloading by method signature Hans, such overloading would be incompatible with php's dynamic nature As far as I remember, even type-hinting for basic-types (strings, integers) was rejected On 10/13/07, Hans Moog <hans.moog@mkj-computing.de> wrote:
> Will method overloading by method signature be implemented in php6 or > even php 5.3? > > > > Example: > > <?php > > namespace xyz; > > > > import core::TestClass; > > > > class Test extends TestClass { > > public string function test(integer $int) { > > return "Hi"; > } > > > > public integer function test(string $string, integer $int) { > > return $int; > } > } > > ?> > > > > I think this would be a very big advantage and would help developers to > write better code. > >
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Alexey Zakhlestin

18 years ago
can your patch handle the following situation? how? class A { public function fun1($a) { //… } public function fun1($a, $b) { //… } } $a = new A(); $a->fun1('a', 'b', 'c'); // which method is called here? On 10/14/07, Hans Moog <hans.moog@mkj-computing.de> wrote: > Why would it be incompatible with php's dynamic nature? (I already heard many people saying "that this is not the php way") But why ? Don't you like it or do you think it is just not possible to be implemented in php? > > I could provide a patch that makes it possible (even with complete visibility and inheritance rules). We already use it and it saves us a lot of code. > > I think it is better than the '$x = "defaultValue"' kind of way to accept different count and types of parameters because it is MUCH more expressive and intuitive. > > It wouldn't even break backward compatibility beause it is just "syntactical sugar" to checking the variable types manually and then dispatching to the right behaviour. > > -----Ursprüngliche Nachricht----- > Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] > Gesendet: Samstag, 13. Oktober 2007 22:22 > An: Hans Moog > Cc: internals@lists.php.net > Betreff: Re: [PHP-DEV] Method overloading by method signature > > Hans, such overloading would be incompatible with php's dynamic nature > As far as I remember, even type-hinting for basic-types (strings, > integers) was rejected > > On 10/13/07, Hans Moog <hans.moog@mkj-computing.de> wrote: > > Will method overloading by method signature be implemented in php6 or > > even php 5.3? > > > > > > > > Example: > > > > <?php > > > > namespace xyz; > > > > > > > > import core::TestClass; > > > > > > > > class Test extends TestClass { > > > > public string function test(integer $int) { > > > > return "Hi"; > > } > > > > > > > > public integer function test(string $string, integer $int) { > > > > return $int; > > } > > } > > > > ?> > > > > > > > > I think this would be a very big advantage and would help developers to > > write better code. > > > > > > > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ > > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Hans Moog

18 years ago
It shows an error that fun1 is not implemented for the signature of the passed parameters. But you could still provide a method that matches any number and type of parameters by adding the following method declaration. /** * This method accepts parameters of any type and any count. */ public function fun1($parameters ...) { /* * array(3) { * [0] => string(1) "a" * [1] => string(2) "b" * [2] => string(3) "c" * } */ var_dump($parameters); } The "..." notation (making it possible to have a dynamic count of parameters of the given type (missing typehint automatically chooses mixed)) is only allowed for the last parameter. So method defintions like the following one are also possible: public function fun1(string $firstParam, string $remainingParameters ...) { /* * string(1) "a" */ var_dump($firstParam); /* * array(3) { * [0] => string(1) "b" * [1] => string(2) "c" * } */ var_dump($remainingParameters); } -----Ursprüngliche Nachricht----- Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] Gesendet: Samstag, 13. Oktober 2007 23:20 An: Hans Moog Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] Method overloading by method signature can your patch handle the following situation? how? class A { public function fun1($a) { //… } public function fun1($a, $b) { //… } } $a = new A(); $a->fun1('a', 'b', 'c'); // which method is called here? On 10/14/07, Hans Moog <hans.moog@mkj-computing.de> wrote:
> Why would it be incompatible with php's dynamic nature? (I already heard many people saying "that this is not the php way") But why ? Don't you like it or do you think it is just not possible to be implemented in php? > > I could provide a patch that makes it possible (even with complete visibility and inheritance rules). We already use it and it saves us a lot of code. > > I think it is better than the '$x = "defaultValue"' kind of way to accept different count and types of parameters because it is MUCH more expressive and intuitive. > > It wouldn't even break backward compatibility beause it is just "syntactical sugar" to checking the variable types manually and then dispatching to the right behaviour. > > -----Ursprüngliche Nachricht----- > Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] > Gesendet: Samstag, 13. Oktober 2007 22:22 > An: Hans Moog > Cc: internals@lists.php.net > Betreff: Re: [PHP-DEV] Method overloading by method signature > > Hans, such overloading would be incompatible with php's dynamic nature > As far as I remember, even type-hinting for basic-types (strings, > integers) was rejected > > On 10/13/07, Hans Moog <hans.moog@mkj-computing.de> wrote: > > Will method overloading by method signature be implemented in php6 or > > even php 5.3? > > > > > > > > Example: > > > > <?php > > > > namespace xyz; > > > > > > > > import core::TestClass; > > > > > > > > class Test extends TestClass { > > > > public string function test(integer $int) { > > > > return "Hi"; > > } > > > > > > > > public integer function test(string $string, integer $int) { > > > > return $int; > > } > > } > > > > ?> > > > > > > > > I think this would be a very big advantage and would help developers to > > write better code. > > > > > > > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ > > >
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Alexey Zakhlestin

18 years ago
On 10/14/07, Hans Moog <hans.moog@mkj-computing.de> wrote: > It shows an error that fun1 is not implemented for the signature of the passed parameters. > > But you could still provide a method that matches any number and type of parameters by adding the following method declaration. Well, this looks exactly like incompatibility to me, because currently any function accepts any number of parameters (and you get non-explicit ones by using func_get_args()) > > /** > * This method accepts parameters of any type and any count. > */ > public function fun1($parameters ...) { > /* > * array(3) { > * [0] => string(1) "a" > * [1] => string(2) "b" > * [2] => string(3) "c" > * } > */ > var_dump($parameters); > } > > > The "..." notation (making it possible to have a dynamic count of parameters of the given type (missing typehint automatically chooses mixed)) is only allowed for the last parameter. > > So method defintions like the following one are also possible: > > > public function fun1(string $firstParam, string $remainingParameters ...) { > /* > * string(1) "a" > */ > var_dump($firstParam); > > /* > * array(3) { > * [0] => string(1) "b" > * [1] => string(2) "c" > * } > */ > var_dump($remainingParameters); > } > > -----Ursprüngliche Nachricht----- > Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] > Gesendet: Samstag, 13. Oktober 2007 23:20 > An: Hans Moog > Cc: internals@lists.php.net > Betreff: Re: [PHP-DEV] Method overloading by method signature > > can your patch handle the following situation? how? > > class A > { > public function fun1($a) > { > //… > } > > public function fun1($a, $b) > { > //… > } > } > > $a = new A(); > $a->fun1('a', 'b', 'c'); // which method is called here? > > On 10/14/07, Hans Moog <hans.moog@mkj-computing.de> wrote: > > Why would it be incompatible with php's dynamic nature? (I already heard many people saying "that this is not the php way") But why ? Don't you like it or do you think it is just not possible to be implemented in php? > > > > I could provide a patch that makes it possible (even with complete visibility and inheritance rules). We already use it and it saves us a lot of code. > > > > I think it is better than the '$x = "defaultValue"' kind of way to accept different count and types of parameters because it is MUCH more expressive and intuitive. > > > > It wouldn't even break backward compatibility beause it is just "syntactical sugar" to checking the variable types manually and then dispatching to the right behaviour. > > > > -----Ursprüngliche Nachricht----- > > Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] > > Gesendet: Samstag, 13. Oktober 2007 22:22 > > An: Hans Moog > > Cc: internals@lists.php.net > > Betreff: Re: [PHP-DEV] Method overloading by method signature > > > > Hans, such overloading would be incompatible with php's dynamic nature > > As far as I remember, even type-hinting for basic-types (strings, > > integers) was rejected > > > > On 10/13/07, Hans Moog <hans.moog@mkj-computing.de> wrote: > > > Will method overloading by method signature be implemented in php6 or > > > even php 5.3? > > > > > > > > > > > > Example: > > > > > > <?php > > > > > > namespace xyz; > > > > > > > > > > > > import core::TestClass; > > > > > > > > > > > > class Test extends TestClass { > > > > > > public string function test(integer $int) { > > > > > > return "Hi"; > > > } > > > > > > > > > > > > public integer function test(string $string, integer $int) { > > > > > > return $int; > > > } > > > } > > > > > > ?> > > > > > > > > > > > > I think this would be a very big advantage and would help developers to > > > write better code. > > > > > > > > > > > > -- > > Alexey Zakhlestin > > http://blog.milkfarmsoft.com/ > > > > > > > > > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ > > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Hans Moog

18 years ago
As long as you only got one method per name it doesn't change things, so it wouldn't brake backward compatibility and old functions would still behave like expected (so it is not incompatible). But if you want to be more strict and limit the coder to use your functions only with a specific parameter signature (and thats the only reason to use type hints - to ensure the method is used correctly and build more robust applications), it is better to tell the coder that he made a mistake than just going on and guessing which method to call. The new PHP5 object model introduces signature checking (yay!) but since PHP doesn't allow overloading a great deal of flexibilty was lost in this move (boo!). No longer can you override a method & provide an incompatible signature. This mixture of strict OO + PHP's traditional loose typing is really shooting PHP in the foot. I think, that this ist the reason why nearly nobody uses this great new feature (to ensure that the passed parameters are correct), because when he does, he isn't able to provide different ways to use a method anymore. And allowing signature checks would really enhance php's security because an integer id (for example) can never be used to insert malicious sql into an sql statement and by that create an sql injection. You wouldn't have to put a mysql_escape_string (or integer typecast) around every single parameter anymore because you would be able to rely on an integer id, really being an integer id without messing around with thousands of custom checks (that would even boost performance since string operations are always a bit slow). And like i already said - this "new feature" wouldn't make php a strong typed language (you would still have all the possibilities of using variables as different types), it would just offer the coder a method to write more strict method declarations that would definitly enhance the performance, security an robustness of applications. -----Ursprüngliche Nachricht----- Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] Gesendet: Sonntag, 14. Oktober 2007 10:04 An: Hans Moog Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] Method overloading by method signature On 10/14/07, Hans Moog <hans.moog@mkj-computing.de> wrote:
> It shows an error that fun1 is not implemented for the signature of the passed parameters. > > But you could still provide a method that matches any number and type of parameters by adding the following method declaration.
Well, this looks exactly like incompatibility to me, because currently any function accepts any number of parameters (and you get non-explicit ones by using func_get_args())
> > /** > * This method accepts parameters of any type and any count. > */ > public function fun1($parameters ...) { > /* > * array(3) { > * [0] => string(1) "a" > * [1] => string(2) "b" > * [2] => string(3) "c" > * } > */ > var_dump($parameters); > } > > > The "..." notation (making it possible to have a dynamic count of parameters of the given type (missing typehint automatically chooses mixed)) is only allowed for the last parameter. > > So method defintions like the following one are also possible: > > > public function fun1(string $firstParam, string $remainingParameters ...) { > /* > * string(1) "a" > */ > var_dump($firstParam); > > /* > * array(3) { > * [0] => string(1) "b" > * [1] => string(2) "c" > * } > */ > var_dump($remainingParameters); > } > > -----Ursprüngliche Nachricht----- > Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] > Gesendet: Samstag, 13. Oktober 2007 23:20 > An: Hans Moog > Cc: internals@lists.php.net > Betreff: Re: [PHP-DEV] Method overloading by method signature > > can your patch handle the following situation? how? > > class A > { > public function fun1($a) > { > //… > } > > public function fun1($a, $b) > { > //… > } > } > > $a = new A(); > $a->fun1('a', 'b', 'c'); // which method is called here? > > On 10/14/07, Hans Moog <hans.moog@mkj-computing.de> wrote: > > Why would it be incompatible with php's dynamic nature? (I already heard many people saying "that this is not the php way") But why ? Don't you like it or do you think it is just not possible to be implemented in php? > > > > I could provide a patch that makes it possible (even with complete visibility and inheritance rules). We already use it and it saves us a lot of code. > > > > I think it is better than the '$x = "defaultValue"' kind of way to accept different count and types of parameters because it is MUCH more expressive and intuitive. > > > > It wouldn't even break backward compatibility beause it is just "syntactical sugar" to checking the variable types manually and then dispatching to the right behaviour. > > > > -----Ursprüngliche Nachricht----- > > Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] > > Gesendet: Samstag, 13. Oktober 2007 22:22 > > An: Hans Moog > > Cc: internals@lists.php.net > > Betreff: Re: [PHP-DEV] Method overloading by method signature > > > > Hans, such overloading would be incompatible with php's dynamic nature > > As far as I remember, even type-hinting for basic-types (strings, > > integers) was rejected > > > > On 10/13/07, Hans Moog <hans.moog@mkj-computing.de> wrote: > > > Will method overloading by method signature be implemented in php6 or > > > even php 5.3? > > > > > > > > > > > > Example: > > > > > > <?php > > > > > > namespace xyz; > > > > > > > > > > > > import core::TestClass; > > > > > > > > > > > > class Test extends TestClass { > > > > > > public string function test(integer $int) { > > > > > > return "Hi"; > > > } > > > > > > > > > > > > public integer function test(string $string, integer $int) { > > > > > > return $int; > > > } > > > } > > > > > > ?> > > > > > > > > > > > > I think this would be a very big advantage and would help developers to > > > write better code. > > > > > > > > > > > > -- > > Alexey Zakhlestin > > http://blog.milkfarmsoft.com/ > > > > > > > > > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ > > >
-- Alexey Zakhlestin http://blog.milkfarmsoft.com/

Stanislav Malyshev

18 years ago
> But if you want to be more strict and limit the coder to use your > functions only with a specific parameter signature (and thats the
The purpose of signature overloading in most languages isn't input type control, it's different functionality on different types. However, unlike many other languages, PHP does not have static typing, and that would not allow to know which function is called immediately, only at runtime. This has both performance impact and code transparency impact - you wouldn't know which function will be called until runtime. I am not convinced this added complexity serves any real need - though you are welcome to prove otherwise, i.e. present some use case when one can't do without signature overloading.
> only reason to use type hints - to ensure the method is used > correctly and build more robust applications), it is better to tell
BTW, I'm not sure how exactly it makes the code more robust - if you call it with wrong type and it's not checked, the app would probably die on fatal error. If you call it with wrong type and it is checked, the app would die on fatal error couple of lines above. Unless you use some kind of static analysis tool to verify your app prior to deployment (if you know such tools please tell me!) I don't see much difference here, mostly syntax sugar and enforcing right style (which is not bad - just it's not that big a deal).
> lost in this move (boo!). No longer can you override a method & > provide an incompatible signature. This mixture of strict OO + PHP's > traditional loose typing is really shooting PHP in the foot.
If you don't want strict signatures - why you are using them? Nobody forces you to type your arguments. And inheritance is certainly not for overriding objects with incompatible signatures, if you try to do it you are misusing it.
> I think, that this ist the reason why nearly nobody uses this great > new feature (to ensure that the passed parameters are correct),
The above statement is not true. This feature is used by many developers. Please stop using "unless you do it my way, nobody will use PHP" argument - it doesn't work.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Umberto Salsi

18 years ago
Posting to newsgroup php.internals, you wrote:
> > But if you want to be more strict and limit the coder to use your > > functions only with a specific parameter signature (and thats the > > The purpose of signature overloading in most languages isn't input type > control, it's different functionality on different types. However, > unlike many other languages, PHP does not have static typing, and that > would not allow to know which function is called immediately, only at > runtime. This has both performance impact and code transparency impact - > you wouldn't know which function will be called until runtime. I am not > convinced this added complexity serves any real need - though you are > welcome to prove otherwise, i.e. present some use case when one can't do > without signature overloading. > > > only reason to use type hints - to ensure the method is used > > correctly and build more robust applications), it is better to tell > > BTW, I'm not sure how exactly it makes the code more robust - if you > call it with wrong type and it's not checked, the app would probably die > on fatal error. If you call it with wrong type and it is checked, the > app would die on fatal error couple of lines above. Unless you use some > kind of static analysis tool to verify your app prior to deployment (if > you know such tools please tell me!) I don't see much difference here, > mostly syntax sugar and enforcing right style (which is not bad - just > it's not that big a deal). > > > lost in this move (boo!). No longer can you override a method & > > provide an incompatible signature. This mixture of strict OO + PHP's > > traditional loose typing is really shooting PHP in the foot. > > If you don't want strict signatures - why you are using them? Nobody > forces you to type your arguments. And inheritance is certainly not for > overriding objects with incompatible signatures, if you try to do it you > are misusing it. > > > I think, that this ist the reason why nearly nobody uses this great > > new feature (to ensure that the passed parameters are correct), > > The above statement is not true. This feature is used by many > developers. Please stop using "unless you do it my way, nobody will use > PHP" argument - it doesn't work. > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com
Ciao, ___ /_|_\ Umberto Salsi \/_\/ www.icosaedro.it

Umberto Salsi

18 years ago
Posting to newsgroup php.internals, Stanislav Malyshev wrote:
> > only reason to use type hints - to ensure the method is used > > correctly and build more robust applications), it is better to tell > > BTW, I'm not sure how exactly it makes the code more robust - if you > call it with wrong type and it's not checked, the app would probably die > on fatal error. If you call it with wrong type and it is checked, the > app would die on fatal error couple of lines above. Unless you use some > kind of static analysis tool to verify your app prior to deployment (if > you know such tools please tell me!) I don't see much difference here, > mostly syntax sugar and enforcing right style (which is not bad - just > it's not that big a deal).
Most of the current applications of PHP do not need strict type checking, and PHP as we know today perfectly fits these needs. But debugging and "cleaning" large applications may become a nightmare. That's why I developed PHPLint, a PHP parser and validator that performs a static analysis of the source, ensuring the safe handling of types. In a word, this tool makes PHP very close to a strong-typed language without the need to further complicate the interpreter with new features that would pervert the nature of the language. Every constant, variable, property has a well defined type, and every function and method has a well defined signature that can be guessed by PHPLint or provided through specific meta-code as in this example: $i = 123; # type of the variable guessed as int define("RND_K", 1.0 / (1.0 + getrandmax())); # type of the constant guessed as double function rnd() { return RND_K * rand(); } # signature guessed as float() $i = rnd(); # ERROR: assigning double to int function textToattribute(/*.string.*/ $a) { return "\"" . htmlspecialchars($a) . "\""; } # signature string(string) Best regards, ___ /_|_\ Umberto Salsi \/_\/ www.icosaedro.it

Hans Moog

18 years ago
Yeah PHPLint is cool and very useful when you want to be strict. We do use it regularly. But it doesn't enable you to overload your methods as described because this could only be done by a native language construct or manual type checks and dispatching. I thought it would be a good idea to embed this into the language because php is getting more and more object oriented and overloading functions is one of the basic features of an object oriented programming language. Overloading is already possible but php doesn't offer the coder a short syntax to support him writing oveloaded functions. I would love to see a solution for simpler overloading since that would result in a better readability of code. But since I and Richard Quadling seem to be the only ones who would like to have this feature in php, I will put no further effort in this request and comply to the will of the majority :| Perhaps a later release of php will have this feature. (After all, even namespace support was added and nobody wanted namespaces at first, because it was not the "php way" - so there is still hope :P ) -----Ursprüngliche Nachricht----- Von: Umberto Salsi [mailto:salsi@icosaedro.it] Gesendet: Montag, 15. Oktober 2007 16:36 An: internals@lists.php.net Betreff: Re: AW: [PHP-DEV] Method overloading by method signature Posting to newsgroup php.internals, Stanislav Malyshev wrote:
> > only reason to use type hints - to ensure the method is used > > correctly and build more robust applications), it is better to tell > > BTW, I'm not sure how exactly it makes the code more robust - if you > call it with wrong type and it's not checked, the app would probably die > on fatal error. If you call it with wrong type and it is checked, the > app would die on fatal error couple of lines above. Unless you use some > kind of static analysis tool to verify your app prior to deployment (if > you know such tools please tell me!) I don't see much difference here, > mostly syntax sugar and enforcing right style (which is not bad - just > it's not that big a deal).
Most of the current applications of PHP do not need strict type checking, and PHP as we know today perfectly fits these needs. But debugging and "cleaning" large applications may become a nightmare. That's why I developed PHPLint, a PHP parser and validator that performs a static analysis of the source, ensuring the safe handling of types. In a word, this tool makes PHP very close to a strong-typed language without the need to further complicate the interpreter with new features that would pervert the nature of the language. Every constant, variable, property has a well defined type, and every function and method has a well defined signature that can be guessed by PHPLint or provided through specific meta-code as in this example: $i = 123; # type of the variable guessed as int define("RND_K", 1.0 / (1.0 + getrandmax())); # type of the constant guessed as double function rnd() { return RND_K * rand(); } # signature guessed as float() $i = rnd(); # ERROR: assigning double to int function textToattribute(/*.string.*/ $a) { return "\"" . htmlspecialchars($a) . "\""; } # signature string(string) Best regards, ___ /_|_\ Umberto Salsi \/_\/ www.icosaedro.it
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Stanislav Malyshev

18 years ago
> That's why I developed PHPLint, a PHP parser and validator that performs > a static analysis of the source, ensuring the safe handling of types. In > a word, this tool makes PHP very close to a strong-typed language without > the need to further complicate the interpreter with new features that would > pervert the nature of the language.
I think this is better solution than messing with the language :)
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Marcus Börger

18 years ago
Hello Umberto, Monday, October 15, 2007, 3:36:22 PM, you wrote:
> Posting to newsgroup php.internals, Stanislav Malyshev wrote:
>> > only reason to use type hints - to ensure the method is used >> > correctly and build more robust applications), it is better to tell >> >> BTW, I'm not sure how exactly it makes the code more robust - if you >> call it with wrong type and it's not checked, the app would probably die >> on fatal error. If you call it with wrong type and it is checked, the >> app would die on fatal error couple of lines above. Unless you use some >> kind of static analysis tool to verify your app prior to deployment (if >> you know such tools please tell me!) I don't see much difference here, >> mostly syntax sugar and enforcing right style (which is not bad - just >> it's not that big a deal).
> Most of the current applications of PHP do not need strict type checking, and > PHP as we know today perfectly fits these needs. But debugging and "cleaning" > large applications may become a nightmare.
> That's why I developed PHPLint,
I think this is a very nice tool and the way to go in PHP. You should showcase demo it on one of the conferences! And provide links here of course :-) marcus
> a PHP parser and validator that performs > a static analysis of the source, ensuring the safe handling of types. In > a word, this tool makes PHP very close to a strong-typed language without > the need to further complicate the interpreter with new features that would > pervert the nature of the language.
> Every constant, variable, property has a well defined type, and every > function and method has a well defined signature that can be guessed by > PHPLint or provided through specific meta-code as in this example:
> $i = 123; > # type of the variable guessed as int
> define("RND_K", 1.0 / (1.0 + getrandmax())); > # type of the constant guessed as double
> function rnd() > { > return RND_K * rand(); > } > # signature guessed as float()
> $i = rnd(); > # ERROR: assigning double to int
> function textToattribute(/*.string.*/ $a) > { > return "\"" . htmlspecialchars($a) . "\""; > } > # signature string(string)
> Best regards, > ___ > /_|_\ Umberto Salsi > \/_\/ www.icosaedro.it
Best regards, Marcus

Marcus Börger

18 years ago
Hello Hans, 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. marcus Saturday, October 13, 2007, 10:47:23 PM, you wrote:
> Why would it be incompatible with php's dynamic nature? (I already heard > many people saying "that this is not the php way") But why ? Don't you > like it or do you think it is just not possible to be implemented in php?
> I could provide a patch that makes it possible (even with complete > visibility and inheritance rules). We already use it and it saves us a lot of code.
> I think it is better than the '$x = "defaultValue"' kind of way to accept > different count and types of parameters because it is MUCH more expressive and intuitive.
> It wouldn't even break backward compatibility beause it is just > "syntactical sugar" to checking the variable types manually and then dispatching to the right behaviour.
> -----Ursprüngliche Nachricht----- > Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] > Gesendet: Samstag, 13. Oktober 2007 22:22 > An: Hans Moog > Cc: internals@lists.php.net > Betreff: Re: [PHP-DEV] Method overloading by method signature
> Hans, such overloading would be incompatible with php's dynamic nature > As far as I remember, even type-hinting for basic-types (strings, > integers) was rejected
> On 10/13/07, Hans Moog <hans.moog@mkj-computing.de> wrote: >> Will method overloading by method signature be implemented in php6 or >> even php 5.3? >> >> >> >> Example: >> >> <?php >> >> namespace xyz; >> >> >> >> import core::TestClass; >> >> >> >> class Test extends TestClass { >> >> public string function test(integer $int) { >> >> return "Hi"; >> } >> >> >> >> public integer function test(string $string, integer $int) { >> >> return $int; >> } >> } >> >> ?> >> >> >> >> I think this would be a very big advantage and would help developers to >> write better code. >> >>
Best regards, Marcus

Hans Moog

18 years ago
I will do so, but i will have to modify it to work with the current php version and I wanted to know if everybody hates this way of method overloading first. Btw: We made some benchmark tests when we decided to use it. And the method calls were about 0.1 Percent slower. But without having to check or escape every parameter anymore it even boosts performance for us, since we really try to build very robust applications and because of that check all parameters that could be problematic. But if you write quick and dirty code without thinking about sql injections or other problems and not checking anyhting, it is definitly a bit slower (about 0.1 percent of a normal method call). But I think this loss of performance is worth it since the current way of php's mixture of strict OO + traditional loose typing is really shooting PHP in the foot. (Nobody will ever really use typehinting when he want's to offer a number of ways to use a method). -----Ursprüngliche Nachricht----- Von: Marcus Boerger [mailto:helly@php.net] Gesendet: Sonntag, 14. Oktober 2007 09:29 An: Hans Moog Cc: Alexey Zakhlestin; internals@lists.php.net Betreff: Re: AW: [PHP-DEV] Method overloading by method signature Hello Hans, 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. marcus Saturday, October 13, 2007, 10:47:23 PM, you wrote:
> Why would it be incompatible with php's dynamic nature? (I already heard > many people saying "that this is not the php way") But why ? Don't you > like it or do you think it is just not possible to be implemented in php?
> I could provide a patch that makes it possible (even with complete > visibility and inheritance rules). We already use it and it saves us a lot of code.
> I think it is better than the '$x = "defaultValue"' kind of way to accept > different count and types of parameters because it is MUCH more expressive and intuitive.
> It wouldn't even break backward compatibility beause it is just > "syntactical sugar" to checking the variable types manually and then dispatching to the right behaviour.
> -----Ursprüngliche Nachricht----- > Von: Alexey Zakhlestin [mailto:indeyets@gmail.com] > Gesendet: Samstag, 13. Oktober 2007 22:22 > An: Hans Moog > Cc: internals@lists.php.net > Betreff: Re: [PHP-DEV] Method overloading by method signature
> Hans, such overloading would be incompatible with php's dynamic nature > As far as I remember, even type-hinting for basic-types (strings, > integers) was rejected
> On 10/13/07, Hans Moog <hans.moog@mkj-computing.de> wrote: >> Will method overloading by method signature be implemented in php6 or >> even php 5.3? >> >> >> >> Example: >> >> <?php >> >> namespace xyz; >> >> >> >> import core::TestClass; >> >> >> >> class Test extends TestClass { >> >> public string function test(integer $int) { >> >> return "Hi"; >> } >> >> >> >> public integer function test(string $string, integer $int) { >> >> return $int; >> } >> } >> >> ?> >> >> >> >> I think this would be a very big advantage and would help developers to >> write better code. >> >>
Best regards, Marcus
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Stanislav Malyshev

18 years ago
> Btw: We made some benchmark tests when we decided to use it. And the > method calls were about 0.1 Percent slower. But without having to > check or escape every parameter anymore it even boosts performance
If you think parameter typing would free you from having input validation, IMHO you are on a wrong way.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Marcus Börger

18 years ago
Hello Hans, Sunday, October 14, 2007, 1:11:35 PM, you wrote:
> I will do so, but i will have to modify it to work with the current php > version and I wanted to know if everybody hates this way of method overloading first.
> Btw: We made some benchmark tests when we decided to use it. And the > method calls were about 0.1 Percent slower. But without having to check or > escape every parameter anymore it even boosts performance for us, since we > really try to build very robust applications and because of that check all > parameters that could be problematic.
> But if you write quick and dirty code without thinking about sql > injections or other problems and not checking anyhting, it is definitly a > bit slower (about 0.1 percent of a normal method call).
> But I think this loss of performance is worth it since the current way of > php's mixture of strict OO + traditional loose typing is really shooting > PHP in the foot. (Nobody will ever really use typehinting when he want's > to offer a number of ways to use a method).
Reading this it occurs to me that you are on a completely wrong track. PHP is untyped for a good reason. It was a choice to deal with the untyped web environment. Later we added type hints to help code readability. Yet OOP is only a small apspect of PHP and always will be. That said the language for you would probably have another one. Also type hinting and overloading do not in any way free you from filtering and escaping. If you think so you may test your code again and hopefuly not find too many security holes. The reason I asked for performance impact is that in general we do not like to add features that are not necessary for the web environment but have a negative impact on it. Also reading of an impact of 0.1 percent seems very strange as basically anything below 2% is close to the measurable limit and the onlt way to measure such tiny impacts would be counting assembled instructions using callgrind. Last but not least we added typehints to enable developers to generate better understandable error messages. These go especially well with the typical easy PHP application designs and PHPs stack trace ability in exception handling. marcus

Timm Friebe

18 years ago
Hi, [...]
> Later we added type hints to help code readability.
Let me jump at this: == function xpath($arg) { if ($arg instanceof DomDocument) { return new DomXPath($arg); } else if ($arg instanceof XmlTree) { return new DomXPath($this->loadXML($arg->getSource())); } else if (is_string($arg)) { return new DomXPath($this->loadXML($arg)); } else { throw new IllegalArgumentException('Unsupported argument type'); } } == vs. == function xpath(DomDocument $arg) { return new DomXPath($arg); } function xpath(XmlTree $arg) { return new DomXPath($this->loadXML($arg->getSource()))); } function xpath($arg) { // Untyped = default if (!is_string($arg)) { throw new IllegalArgumentException('Unsupported argument type'); } return new DomXPath($this->loadXML($arg)); } == If we consider the readability argument only: Which one of the above more readable? You decide:) - Timm

Hans Moog

18 years ago
When it would be: == function xpath(DomDocument $arg) { return new DomXPath($arg); } function xpath(XmlTree $arg) { return new DomXPath($this->loadXML($arg->getSource()))); } function xpath(string $arg) { return new DomXPath($this->loadXML($arg)); } == (since when method overloding by sigantures wer put into php, scalar types should be possible, too, shouldn't they?) I would prefer the second one because I understand the behaviour much faster than analyzing the if switch (and this if switch is really simple to understand because there is only one command in every block). The second reason for me to select the second version is, that I am able to write better documentation for each behaviour (although, in this situation there isn't that much to be commented). -----Ursprüngliche Nachricht----- Von: Timm Friebe [mailto:thekid@thekid.de] Gesendet: Montag, 15. Oktober 2007 20:47 An: internals@lists.php.net Betreff: Re: [PHP-DEV] Method overloading by method signature Hi, [...]
> Later we added type hints to help code readability.
Let me jump at this: == function xpath($arg) { if ($arg instanceof DomDocument) { return new DomXPath($arg); } else if ($arg instanceof XmlTree) { return new DomXPath($this->loadXML($arg->getSource())); } else if (is_string($arg)) { return new DomXPath($this->loadXML($arg)); } else { throw new IllegalArgumentException('Unsupported argument type'); } } == vs. == function xpath(DomDocument $arg) { return new DomXPath($arg); } function xpath(XmlTree $arg) { return new DomXPath($this->loadXML($arg->getSource()))); } function xpath($arg) { // Untyped = default if (!is_string($arg)) { throw new IllegalArgumentException('Unsupported argument type'); } return new DomXPath($this->loadXML($arg)); } == If we consider the readability argument only: Which one of the above more readable? You decide:) - Timm
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Richard Quadling

18 years ago
On 15/10/2007, Hans Moog <hans.moog@mkj-computing.de> wrote: > When it would be: > > == > function xpath(DomDocument $arg) { > return new DomXPath($arg); > } > > function xpath(XmlTree $arg) { > return new DomXPath($this->loadXML($arg->getSource()))); > } > > function xpath(string $arg) { > return new DomXPath($this->loadXML($arg)); > } > == > > (since when method overloding by sigantures wer put into php, scalar types should be possible, too, shouldn't they?) > > I would prefer the second one because I understand the behaviour much faster than analyzing the if switch (and this if switch is really simple to understand because there is only one command in every block). The second reason for me to select the second version is, that I am able to write better documentation for each behaviour (although, in this situation there isn't that much to be commented). > > -----Ursprüngliche Nachricht----- > Von: Timm Friebe [mailto:thekid@thekid.de] > Gesendet: Montag, 15. Oktober 2007 20:47 > An: internals@lists.php.net > Betreff: Re: [PHP-DEV] Method overloading by method signature > > Hi, > > [...] > > Later we added type hints to help code readability. > > Let me jump at this: > > == > function xpath($arg) { > if ($arg instanceof DomDocument) { > return new DomXPath($arg); > } else if ($arg instanceof XmlTree) { > return new DomXPath($this->loadXML($arg->getSource())); > } else if (is_string($arg)) { > return new DomXPath($this->loadXML($arg)); > } else { > throw new IllegalArgumentException('Unsupported argument type'); > } > } > > == vs. == > > function xpath(DomDocument $arg) { > return new DomXPath($arg); > } > > function xpath(XmlTree $arg) { > return new DomXPath($this->loadXML($arg->getSource()))); > } > > function xpath($arg) { // Untyped = default > if (!is_string($arg)) { > throw new IllegalArgumentException('Unsupported argument type'); > } > return new DomXPath($this->loadXML($arg)); > } > > == > > If we consider the readability argument only: Which one of the above more > readable? You decide:) > > - Timm As the PHP Documentation may have to is starting adding multiple signatures (Docbook has no mechanism if grouping optional parameters it seems), it seems only fair that PHP itself should (flame-retardant suit fully fitted) "catch-up". (Hey when has documentation EVER been ahead of the game!?!). If this feature makes PHP (or at least some aspects of it), a typed language, then that's OK by me. It means my code is more consistent with other languages. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Stanislav Malyshev

18 years ago
> suit fully fitted) "catch-up". (Hey when has documentation EVER been > ahead of the game!?!).
Always? Otherwise there would be no need for documentation, if everything was in the code. Some people even start with writing docs and only then implement the actual code. Of course, it is not always the case (and some code, like Zend Engine, is so obvious that no docs are needed anyway ;) but documentation containing more insight and more content than the pure code is almost always the case, especially with properly documented code.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Christian Schneider

18 years ago
Hans Moog wrote:
> When it would be: > > == > function xpath(DomDocument $arg) { > return new DomXPath($arg); > } > > function xpath(XmlTree $arg) { > return new DomXPath($this->loadXML($arg->getSource()))); > } > > function xpath(string $arg) { > return new DomXPath($this->loadXML($arg)); > } > ==
function xpathFromDom($arg) { return new DomXPath($arg); } function xpathFromTree($arg) { return new DomXPath($this->loadXML($arg->getSource()))); } function xpathFromString($arg) { return new DomXPath($this->loadXML($arg)); } Works perfectly well. And you don't even need to document them because the names speak for themselves. A much simpler (and clearer) solution IMHO. If you want an OO way I'd prefer something like $xpath = $obj->getXPath(); to $xpath = $this->xpath($obj); anyway. This doesn't work with basic types like strings but having a special case there is not a problem IMHO as using those two interchangeably will lead to other problems anyway. - Chris

Hans Moog

18 years ago
And if you have more than one parameter you will name it methodFromStringIntegerSampleClassBoolean ?!? And how would you do the same for constructors ?!? Create a initWithStringIntegerSampleClassBoolean method which has to be called after object creation ?!? -----Ursprüngliche Nachricht----- Von: Christian Schneider [mailto:cschneid@cschneid.com] Gesendet: Di 16.10.2007 11:45 An: Hans Moog Cc: internals@lists.php.net Betreff: Re: AW: [PHP-DEV] Method overloading by method signature Hans Moog wrote:
> When it would be: > > == > function xpath(DomDocument $arg) { > return new DomXPath($arg); > } > > function xpath(XmlTree $arg) { > return new DomXPath($this->loadXML($arg->getSource()))); > } > > function xpath(string $arg) { > return new DomXPath($this->loadXML($arg)); > } > ==
function xpathFromDom($arg) { return new DomXPath($arg); } function xpathFromTree($arg) { return new DomXPath($this->loadXML($arg->getSource()))); } function xpathFromString($arg) { return new DomXPath($this->loadXML($arg)); } Works perfectly well. And you don't even need to document them because the names speak for themselves. A much simpler (and clearer) solution IMHO. If you want an OO way I'd prefer something like $xpath = $obj->getXPath(); to $xpath = $this->xpath($obj); anyway. This doesn't work with basic types like strings but having a special case there is not a problem IMHO as using those two interchangeably will lead to other problems anyway. - Chris

Johannes Schlueter

18 years ago
Hi, On Mon, 2007-10-15 at 20:47 +0200, "Timm Friebe" wrote:
> function xpath(DomDocument $arg) { > return new DomXPath($arg); > } > > function xpath(XmlTree $arg) { > return new DomXPath($this->loadXML($arg->getSource()))); > } > > function xpath($arg) { // Untyped = default > if (!is_string($arg)) { > throw new IllegalArgumentException('Unsupported argument type'); > } > return new DomXPath($this->loadXML($arg)); > } > > == > > If we consider the readability argument only: Which one of the above more > readable? You decide:)
Allowing an untyped version next to a typed one is imo the worst thing one can do: f I want to read the code and first see the untyped implementation I certainly go crazy while trying to debug the code. johannes

Christian Schneider

18 years ago
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

Rasmus Lerdorf

18 years ago
Christian Schneider wrote:
> 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.
Yup, I agree. Having to sit and count arguments and figure out the types in order to determine which actual method is being called makes it damn near impossible to debug code as far as I am concerned. And what does the callgraph from a profiler look like? kcachegrind doesn't show the function signature in the callgraph which means we would have to map these methods to some unique name and people would have to know how to map these names back to the correct function signature. Sounds like a mess to me. -Rasmus

Hans Moog

18 years ago
Kcachegrind doesn't show the function signature in the callgraph because the parameter signature is not part of the function signature. If the parameter siganture would be moved into the function signature, kcachegrind would adept and show it. Btw: You don't have to use it if you don't want to. But PHP5 didn't include type hints for no reason. The problem: Type hints don't make many sense right now. Like I already wrote in another comment. If you would use type hints you would understand the need of overloading type hinted methods. -----Ursprüngliche Nachricht----- Von: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] Gesendet: Sonntag, 14. Oktober 2007 16:50 An: Christian Schneider Cc: Marcus Boerger; internals@lists.php.net Betreff: Re: AW: [PHP-DEV] Method overloading by method signature Christian Schneider wrote:
> 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.
Yup, I agree. Having to sit and count arguments and figure out the types in order to determine which actual method is being called makes it damn near impossible to debug code as far as I am concerned. And what does the callgraph from a profiler look like? kcachegrind doesn't show the function signature in the callgraph which means we would have to map these methods to some unique name and people would have to know how to map these names back to the correct function signature. Sounds like a mess to me. -Rasmus
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Rasmus Lerdorf

18 years ago
Hans Moog wrote:
> Kcachegrind doesn't show the function signature in the callgraph because the parameter signature is not part of the function signature. If the parameter siganture would be moved into the function signature, kcachegrind would adept and show it. > > Btw: You don't have to use it if you don't want to. But PHP5 didn't include type hints for no reason. The problem: Type hints don't make many sense right now. > Like I already wrote in another comment. If you would use type hints you would understand the need of overloading type hinted methods.
Right, but I am usually profiling and debugging other peoples' code, not my own, so that argument doesn't work. There are plenty of strictly typed languages in the world, we don't need another. The Web is inherently untyped in that browsers don't type anything. We have to intelligently deal with untyped data all the time and do the appropriate type juggling. -Rasmus

Hans Moog

18 years ago
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:cschneid@cschneid.com] 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

Christian Schneider

18 years ago
Hans Moog wrote:
> You are missing something. Using this new feature would be > voluntarily (it is optional like type hints are already).
Thanks for bringing that up right after I told you that I won't accept this argument ;-)
> 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.
We don't check the parameters. Automatic type conversion does the right thing for us in 99% of the case and the other 1% is handled manually. Not checked, handled. Please note the difference.
> 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.
I disagree here: 1. Type hints are not needed for robust applications. That's a myth. They don't even make it easier IMHO. 2. Overloading is not necessary, you can use different names if you want different flavours of a method. That's clearer and easier to debug (I can search in the source code for a function name but not for a parameter signature).
> Btw: You could call foo((integer) $x); to ensure the right method is > called.
That's *exactly* what I want to avoid. Your code ends up being messy for no good reason: Solving a problem you created yourself.
> 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.
I don't think we would agree on what's a complex web application here (complex being a negative term for me, I'd rather write a simple but advanced web application) but even then the API should be simple. And simple APIs don't need whips and chains. And I don't believe in fool proof APIs, only fools can use those ;-) - Chris

Richard Quadling

18 years ago
On 14/10/2007, Hans Moog <hans.moog@mkj-computing.de> wrote:
> 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.
For what it is worth, I would find this functionality EXTREMELY useful. The classes I create ARE used by other developers both within my organisation and outside and as I'm currently porting GUI apps from Delphi to web apps using PHP and missing things like type hinting of scalars AND overloaded function defs is a pain as I now have 1 method with a header which has to parse the parameter types to determine what is required to be called. I think this is a GREAT feature. Even if it was JUST for E_STRICT OOP code.
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Lukas Kahwe Smith

18 years ago
On 13.10.2007, at 18:46, Hans Moog wrote:
> Will method overloading by method signature be implemented in php6 or > even php 5.3?
this feature isnt php .. or rather its a solution to a problem that does not exist in php .. for good reason. regards, Lukas