Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82505
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <aabb5e23729781918c9c8b315af0488b@mail.gmail.com>
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>
	<aabb5e23729781918c9c8b315af0488b@mail.gmail.com>
Date: Thu, 12 Feb 2015 01:11:24 +0100
Message-ID: <CAOjCV8yOJQgJFiCXSCbfAdjcrkJMGFbz3=LrXnQ5rwB5gX+ERw@mail.gmail.com>
To: Zeev Suraski <zeev@zend.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: sbj.ml.read@gmail.com ("Sebastian B.-Hagensen")

Hi,

2015-02-12 0:08 GMT+01:00 Zeev Suraski <zeev@zend.com>:
>  It gives the exact same
> value from an API author=E2=80=99s point of view.

But not from an api-consumers point of view. Without either
introducing a new set of casting/conversion rules or changing existing
behavior  (**exclusively**) 'weak' typehints may be perceived as
seriously crippled. Maybe up to a point where the addition of them
wouldn't be justified.

> But unlike the current RFC, v0.1 doesn=E2=80=99t introduce an IMHO alien =
concept
> into a language that considered dynamic typing to be a core principle sin=
ce
> its birth.

It's not. PHP was always open to enforce strict typing in user created
functions. If types didn't matter the way they do the current
distinguishing between int/float or respectively
array/stdClass/Objects shouldn't exist. But thankfully they are
distinctive. The proposal offers a way to conditionally harmonize
different usage patterns. (Across code bases and with internal
functions)

Having the ability to conditionally tighten rules in self written code
but falling back to loose (in many cases good, in other cases
disastrous) behavior is what modern PHP defines.

To much new code already enforces strict types. Using if(!is_int)
throw new WrongArgumentTypeException() or similar.

The proposed RFC could unify such codebases. Having typehints in the
proposed form would allow the api creator to drop most additional type
checks as the method always receives what was asked for and shifts
responsibility to the user. The way how an API is used would be
determined by the user, allowing them to continue to use the weak
behavior if they want but also offer them to enforce the rules that
otherwise the api creator might force on everyone.

Why don't you want to allow people to use (formerly your) language in
the way they see fit as you have already given them the broader
framework do to so. Having optional strict hints together with the
performance improvements and the maturing php ecosystem
(composer/fig/co. + enterprise-targeting frameworks) may even attract
new users to php that don't want or require the mental burden or the
ecosystem given by other languages(java,c#) but don't want to miss the
additional safety and feeling of strict types.

The other options (globally changing zpp rules and the behavior of
implicit casts) sharing most of the advantages implied in the current
proposal was already proposed as RFC and talked down as the BC break
was considered to big. The concept behind the current RFC (not so much
the syntax) is the only way to satisfy both camps without alienating a
large part of the community. I'd even argue that weak hints alone
wouldn't be able to reach a 2/3 majority as strict supporters (Over
1/3rd of what I've seen on this list) would need be afraid that their
preference would never reach the required majority once weak hints are
in.

It's this proposal, semi-strict hints or changed conversion rules (The
alternatives would either introduce yet another set of unconditional
rules or require a considerable BC break as noted above). Everything
else will either not reach the required majority or will alienate
potentially large parts of the user land community (Which aren't
necessarily known to the oss community, zend or similar).


Thanks