Yes, I can see what you mean. Should a float prefer a string or an int? I
don't know.
That would be a issue unless an additional method of prioritising were
involved. Perhaps if attributes get in there will be a solution:
<<Overloaded(1)>>
function foo(int $a) {}
<<Overloaded(2)>>
function foo(string $a) {}
Yet as complicated as overloading would be to begin with, this I feel would
make it even worse lol.
Just for clarifies sake I'll explain briefly what I feel the benefits are,
and perhaps we can see if it's worth discussing further:
- No need to conjure new names. A biggy IMO.
- A new way of overriding. If you want to override a base class method by
capturing an argument of lower bounds, you won't need to do an instance
check and decide on super or alternative code.
- Performance enhancement over emulated overloads such as __call, variadic
and anonymous arguments.
Regarding the last point, I've mocked up a basic benchmark to illustrate
the difference in performance when comparing emulated overloading with
alternative functions.
I expect native support for overloading to be somewhere in between the
results of the two tests.
https://gist.github.com/orolyn/ff70f512efee36d402d1fc4fbc8f0521
On 6 Jun 2016 12:19 p.m., "Rowan Collins" <rowan.coll...@gmail.com> wrote:
> On 06/06/2016 12:06, Dominic Grostate wrote:
>
>> float, int and string all share the same row on an upside down pyramid,
>> with $bar, being dynamic, at the bottom.
>>
>
> OK, so take away the dynamic case, and assume the caller is in weak mode.
> Now you have a second case where you need priorities between the types.
>
> Or consider this code, which is already valid:
>
> class A { function foo($bar) { echo "A: $bar"; } }
> class B { function foo(int $bar) { echo "B: $bar"; } }
> (new B)->foo(1.5); // B: 1
>
> Or we could construct similar examples with parent and sub-classes as the
> type constraint of $bar. And so on.
>
> I tried to stress that this is an example of one detail among many that
> would need to be worked out; I wasn't looking for a single answer.
>
> Perhaps we would need to add a new keyword (or a native annotation?) to
> mark that a function was overloaded, so that existing inheritance didn't
> accidentally become overloading.
>
> To my mind, this would add a lot of complexity to the language, and I'm
> not convinced of the gain. If you want to avoid dynamically checking
> variable types, you can always just provide separately named methods for
> separate cases.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
