Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80054
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAOsHV+tArSfKv5+RPv0=pNvSJNPT16oUDCzmVGpf5+hhhV5Xzg@mail.gmail.com>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me>
	<CAF+90c-uiLj1QoT+dXfd1obRXNcYcpBAJ-aU59yEXk+HYNZRFw@mail.gmail.com>
	<C0E1AD78-1275-4C0D-81DE-7EF4399216C8@ajf.me>
	<CAOsHV+tArSfKv5+RPv0=pNvSJNPT16oUDCzmVGpf5+hhhV5Xzg@mail.gmail.com>
Date: Thu, 1 Jan 2015 17:29:58 +0100
Message-ID: <CAEra97oCerF9xhqYezQDjzmusL+Dd5n0K9cd-ZuiMU1qDEeJ2A@mail.gmail.com>
To: marcio3w@gmail.com
Cc: Andrea Faulds <ajf@ajf.me>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044280742de53f050b99bcd8
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: nek.dev@gmail.com (Maxime Veber)

--f46d044280742de53f050b99bcd8
Content-Type: text/plain; charset=UTF-8

Woow. The compromise proposed by Marcio looks awesome to me :) .

Andrea, I can understand that in the PHP logic, but IMO if the RFC does not
avoid people that use code like I present before i don't think it's
completely relevant.
I mean, if people still use old tricks because the type hinting doesn't
allow to make what they wanted, then things are not cool enough and should
be re-think. And actually i say that because I see easily me still using
old trick without type hinting... Becaue of this cast story.

Also notice that Marcio's point could be another way, like adding something
with @integer (random operator choice, do not keep that in mind) that make
the check strict... Then IMO this operator will be so much used that it
will not make sence that is not the default behavior.
That's why the proposal of Marcio is cool to me.

2015-01-01 16:59 GMT+01:00 Marcio Almada <marcio.web2@gmail.com>:

> The battle between strict type declarations vs coercive has been here for a
> while. My problem with coercion in detriment of strictness is
> that sometimes you DON'T WANT TYPE CASTING AT ALL. This new feature would
> create serious impediments. So I wonder if we couldn't have both (strict
> and coercive types declarations) and leave the current proposed type
> hinting syntax reserved for strict type declarations? Like in:
>
>     function(int $a, (int) $b) {
>          // $a will be strict
>          // $b will be type casted
>     }
>
> This way we can actually choose when to cast and when to be strict and both
> features could be voted independently without affect each other possible
> future adoptions.
>

--f46d044280742de53f050b99bcd8--