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

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?

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

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/

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

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

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

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!"