Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82527
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.182 as permitted sender)
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>
In-Reply-To: <CFA87680-131D-4382-8B3C-8E13CAF5CA81@ajf.me>
MIME-Version: 1.0
Thread-Index: AQJMIZG9mXkdirFXmuP9r5ZK3xIuzQJbJJA/AzCIQggCYWllLQKBurkXAYsw6s4B6qYCMgHjX/2GAb5UKOABwylnMQKF/fUwm0bANtA=
Date: Thu, 12 Feb 2015 14:31:15 +0200
Message-ID: <77a623e36dcc4b521d58a3f628180dbc@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>, =?UTF-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>
Cc: guilhermeblanco@gmail.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: zeev@zend.com (Zeev Suraski)

> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Thursday, February 12, 2015 1:45 PM
> To: Pavel Kou=C5=99il
> Cc: guilhermeblanco@gmail.com; Zeev Suraski; Rasmus Lerdorf; PHP
> Internals
> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> Hi,
>
> > On 12 Feb 2015, at 07:05, Pavel Kou=C5=99il <pajousek@gmail.com> wrote:
> >
> > On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds <ajf@ajf.me> wrote:
> >>
> >> A number (or numeric, or num, or some other name) type hint is
> something I plan to propose in a future, follow-up RFC.
> >>
> >
> > 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 mig=
ht cause
> unpredictable behaviour (with strict types you=E2=80=99d get an error som=
etimes,
> and
> that=E2=80=99s fine - but calling an entirely different function? Now tha=
t=E2=80=99s
> different.)
> There=E2=80=99s also the question of how, or if at all, method overloadin=
g could
> interact with our optional parameters and dynamic typing. Finally,
> overloading can lead to really poor API design: it=E2=80=99s not that unc=
ommon in
> some languages to see 20 different function definitions with overlapping
> and
> non-comprehensive subsets of a method=E2=80=99s behaviour, that are disti=
nguished
> 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.

+1

Zeev