"Real" method overloading vs Union types

[procodix]

Description

I think it's time to re-raise a question that has only ever been partially answered and implemented in the past, limited by the current state of development of PHP.

How should PHP methods support overloading?

Historically there were the magic methods like __call(). Now there are Union Types and named parameters to allow different signatures for one method. This was called and sold as method overloading, although it is actually not. Union types in particular feel like an extreme step backwards from strong and clean typing. It is no substitute for method overloading, as it requires unsightly type queries in the code and the order is not flexible, not to mention variadic arguments. In a way, Union Types are the counterpoint to method overload. Named parameters mess with variadic arguments and only work together in some limited use cases.

„Method Overloading“ by the book however should allow multiple methods of the same name with different argument lists. Ideally, even static and instance methods with the same name can coexist. In the days when PHP had no typing, this was not feasible. But fortunately that has changed, so now the way is clear.

Sure, you can simulate all of this with __call(), but that destroys any typing and also the IDE support. I think it's time to merge all the partial concepts into a holistic solution of real method overloading, the same way it is offered in other modern languages. Since this could be added as a new language feature, the current substitutes can still be usable for compatibility reasons, albeit less powerful and therefore lower-value.

Constructors are a primary use case, but other methods up to property hooks also benefit from it.

// representing a HTML Element
class Element {
	function fromHtml(string $html) {...}
	function fromContentClasses(string $content, string $classes) {...}
	function fromContentClassesTag(string $content, string $classes, string $tag) {...}
	function fromDom(DOM $dom, string $selector) {…}

	// vs
	
	function __construct(string $html) {…}
	function __construct(string $content, string $classes) {…}
	function __construct(DOM $dom) {…}
	...

	// property hooks with overloading and automatic type conversion
	array $children {
		get {…}
		set(string $html) {…}
		set(array $elements) {…}
		set(Element $e) {...}
	}
}

Please let me know, if it would make sense to put effort into creating an RFC for this.

[iluuu1994]

Why do you think this has been partially answered? It's been discussed to death over many years. It's not that people all agree that it's an undesirable feature (although certainly some do, me included), but it's also that there is no feasible implementation, both in terms of semantics and performance. These limitations mainly come from the fact that the function dispatch part would need to happen at runtime, whereas most (if not all) other languages do so statically.

[procodix]

I followed these debates :) As it is now, PHP surely does heavy checks to ensure type safety while putting parameters on the stack before a method dispatch (which yields runtime errors when types mismatch). I don't known if selecting one of several overloaded methods is more costly compared to this. Especially when assuming there are named parameters involved which have to be brought into order, or variadic arguments which need to be unpacked/merged/repacked before dispatch.

This all feels like it compensates for the missing overloads.

Im not too familiar with PHP internals. Is it safe to say, choosing an overloaded method has to happen at runtime? Their signatures are known at compile time. If function argument types were also known to PHP the way IDEs know them, there sure would be a way.

[iluuu1994]

Is it safe to say, choosing an overloaded method has to happen at runtime? Their signatures are known at compile time. If function argument types were also known to PHP the way IDEs know them, there sure would be a way.

Yes, that's safe to say. PHP compiles each file individually, so if you call foo($someVar) from a.php, and foo() is declared in b.php, we do not know what the signature of this function is. What's worse, even if foo() is declared in a.php, with function overloading we would no longer know if this is the function to be called, because possibly some other file declares a different overload of this function whose signature fits the passed arguments better.

As mentioned, most languages pick the correct overload statically. I.e. they infer function argument types, and then chose which function to call at compile time. However, since PHP doesn't have knowledge about the types of many expressions (again, because they may rely on symbols from other files), it would have to pick the correct overload by looking at the actual values passed to the function. However, these types can change between function calls, which also means that the same foo($value) may trigger a call to foo(int) or foo(float). But what happens if I call foo(string)? With coercion, we could call either. We can say that int has precedence, but that just delays the problem. What about foo(int, float) and foo(float, int) called with foo(string, string)? There are bound to be inconsistencies.

I don't think anybody has ever demonstrated there is actually a good solution to any of these issues, which is why this never goes anywhere when somebody proposes it.

[procodix]

Nice explanation. So union type checks also happen between method invocation and method dispatch?

[iluuu1994]

In terms of the VM, parameter types are always checked at runtime, including union types. Primitive type unions are very fast (a <<-shift and &), unions of classes are more complex (actual loop over the class names). This happens as part of the ZEND_RECV opcode.