Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93839
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
To: PHP internals <internals@lists.php.net>
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>
Message-ID: <37e3870e-9fe4-af80-3e75-2751e33b1a36@gmail.com>
Date: Mon, 6 Jun 2016 12:17:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <CAFKaYMoeL9t-rKsV7Zgjocc=SODCcdjMZsMiM7eBtGgEsSP5rA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Opinion on function/method name overloading
From: rowan.collins@gmail.com (Rowan Collins)

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]