Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82528
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CFA87680-131D-4382-8B3C-8E13CAF5CA81@ajf.me>
References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me>
	<CABBJUpf=wKvGY9+xORRv6WVhCb5+LfRZXGYNasHFS=fz_mwaZQ@mail.gmail.com>
	<CABBJUpeceN1uDK870eV2=znC9f3eaxqYCmaEk0ErH2cbFxTNEw@mail.gmail.com>
	<CABBJUpdYnaR2nztPwFUdDAiAneRrAWzGo-36-DA9hqiBjEHXNA@mail.gmail.com>
	<54DAF884.7000508@lerdorf.com>
	<203e611c8e0b03568a868b8d931aec37@mail.gmail.com>
	<F79D6CDF-20DD-4E24-B2F4-F12637368242@ajf.me>
	<CAFp73XsF37WLzfax-NOgMLf7AU2UodpEz5=ZBMtnuYG+BeMP_w@mail.gmail.com>
	<61E01A7C-C5C8-447F-A8FA-E12A18E847CA@ajf.me>
	<CAB6YZuzW2zBS6t6mY+u1TnxBodG4ru0BTc2z=PR9oKzUcOfXCQ@mail.gmail.com>
	<CFA87680-131D-4382-8B3C-8E13CAF5CA81@ajf.me>
Date: Thu, 12 Feb 2015 13:39:34 +0100
Message-ID: <CAB6YZux_v-sEozOr_moiT1Dyc_NF-YbFbgaBKH=7bPQ4ZvOiDg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>, Zeev Suraski <zeev@zend.com>, 
	Rasmus Lerdorf <rasmus@lerdorf.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

On Thu, Feb 12, 2015 at 12:44 PM, Andrea Faulds <ajf@ajf.me> wrote:
>
> PHP already has polymorphism through its dynamic typing. I don=E2=80=99t =
see method overloading happening any time soon. We have optional parameters=
 and dynamic typing, which all but eliminate the main needs for overloading=
. We=E2=80=99re a weakly-typed language, so overloading on scalar types mig=
ht cause unpredictable behaviour (with strict types you=E2=80=99d get an er=
ror sometimes, and that=E2=80=99s fine - but calling an entirely different =
function? Now that=E2=80=99s different.) There=E2=80=99s also the question =
of how, or if at all, method overloading could interact with our optional p=
arameters and dynamic typing. Finally, overloading can lead to really poor =
API design: it=E2=80=99s not that uncommon in some languages to see 20 diff=
erent function definitions with overlapping and non-comprehensive subsets o=
f a method=E2=80=99s behaviour, that are distinguished only by parameter ty=
pes. It=E2=80=99s one of my least favourite Java/C#/C++ features for that r=
eason.
>
> In response to saying numbers are not a type: well, they are more of an a=
bstract type which integer and float subclass. We already have internal fac=
ilities for converting to and from =E2=80=9Cnumbers=E2=80=9D alongside inte=
gers and floats, I don=E2=80=99t see why we can=E2=80=99t expose this to us=
ers.
>

Hello,

I don't see any problem with combination of optional parameters with
method overloading. C# has it and it is pretty useful and works there
without any bigger issues. Sure, the dynamic typing may be a (small)
issue, but again, C# does it in an IMHO meaningful way as well and it
can be used as an inspiration, should this way be chosen.

Overloading on scalar types - unpredictable how? Even with weak calls,
the best candidate could be chosen? Of course, sometimes there will be
an abmbiguous call, but as long as there would be a way to define
which call you want, it shouldn't be a problem as well?

Poor API - for useland code or in PHP's functions itself? But I don't
think this should be considered as a real problem, because in userland
code, developers are able to create a poor API even with the current
versions of PHP. If someone wants to shoot himself in the foot, he
will do it in one way or another. And at the same time, polymorphism
via method overloading can lead to a cleaner APIs, if it's used well.

Well, about "number" type hint. How this would work, in combination
with strict types?

function bar(float $f) {
    return $f * 1.23;
}

function foo(number $x) {
    return bar($x);
}

foo(1);

From my understanding, it wouldn't?

Regards
Pavel Kouril