Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93841
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <37e3870e-9fe4-af80-3e75-2751e33b1a36@gmail.com>
References: <CAFKaYMq2cfNyhbfmAeaC8cetfnN9cvO_wy+EZVgNkZwAGju3JQ@mail.gmail.com>
	<alpine.DEB.2.20.1606061046300.9660@whisky.home.derickrethans.nl>
	<8b3055e5-706d-ae5e-bbe6-de6ba292ca5b@gmx.de>
	<9b9b33c0-03ff-c147-5105-e4f02901ce6e@gmail.com>
	<CAFKaYMoeL9t-rKsV7Zgjocc=SODCcdjMZsMiM7eBtGgEsSP5rA@mail.gmail.com>
	<37e3870e-9fe4-af80-3e75-2751e33b1a36@gmail.com>
Date: Mon, 6 Jun 2016 13:22:48 +0100
Message-ID: <CAFKaYMqvuSxn=4f7EYh8H2hktFLYV-8mfR78NBuMuR30KuQXUg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1130ccf06dac4405349b21a6
Subject: Re: [PHP-DEV] Opinion on function/method name overloading
From: codekestrel@googlemail.com (Dominic Grostate)

--001a1130ccf06dac4405349b21a6
Content-Type: text/plain; charset=UTF-8

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.collins@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
>
>

--001a1130ccf06dac4405349b21a6--