Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82524
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <CAB6YZuzW2zBS6t6mY+u1TnxBodG4ru0BTc2z=PR9oKzUcOfXCQ@mail.gmail.com>
Date: Thu, 12 Feb 2015 11:44:30 +0000
Cc: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>,
 Zeev Suraski <zeev@zend.com>,
 Rasmus Lerdorf <rasmus@lerdorf.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <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>
To: =?utf-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hi,

> On 12 Feb 2015, at 07:05, Pavel Kou=C5=99il <pajousek@gmail.com> =
wrote:
>=20
> On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds <ajf@ajf.me> wrote:
>>=20
>> A number (or numeric, or num, or some other name) type hint is =
something I plan to propose in a future, follow-up RFC.
>>=20
>=20
> wouldn't polymorphism (via method overloading) solve the use cases and
> be much more useful in the long run than introducing a something
> that's not a type into type hints?

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 might cause unpredictable behaviour (with strict types =
you=E2=80=99d get an error 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 parameters and dynamic =
typing. Finally, overloading can lead to really poor API design: it=E2=80=99=
s not that uncommon in some languages to see 20 different function =
definitions with overlapping and non-comprehensive subsets of a =
method=E2=80=99s behaviour, that are distinguished only by parameter =
types. It=E2=80=99s one of my least favourite Java/C#/C++ features for =
that reason.

In response to saying numbers are not a type: well, they are more of an =
abstract type which integer and float subclass. We already have internal =
facilities for converting to and from =E2=80=9Cnumbers=E2=80=9D =
alongside integers and floats, I don=E2=80=99t see why we can=E2=80=99t =
expose this to users.

Thanks.
--
Andrea Faulds
http://ajf.me/