Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58999
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B806A48BEC0C@MAILR001.mail.lan>
References: <CAJWj5+EwBpeMV__6SN7NbzQ0y4=RDGyg_HueU4N4AZz3Kb=CRQ@mail.gmail.com>
	<CADyq6sL2zbnqcYLpc7UrctPqdK+5TYztytKCxjdVUqUidsRN2g@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B806A48BEC0C@MAILR001.mail.lan>
Date: Sun, 18 Mar 2012 11:41:59 +0100
Message-ID: <CAJWj5+Eg5h7p=o5JRxw8gsRsT_LGGadMbNUqx5RxzRPif6u+Dw@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: Marco Pivetta <ocramius@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
From: simonsimcity@googlemail.com (Simon Schick)

2012/3/18 John Crenshaw <johncrenshaw@priacta.com>:
>
>> =C2=A0 =C2=A0 =C2=A0 2. Unenforced type hinting:
>
> This almost happened in 5.4, but eventually got pulled. More interestingl=
y, the *community* rejected it because it is useless. See the comments at h=
ttp://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.ht=
ml for a good picture of why people hated this idea. Previous discussions o=
n this mailing list also point out that this idea would ultimately be a dea=
d end (a very good catch by...someone...).
>

Hi, John

Thanks for clarifying that way.
I understand why some people want to have that ... to please really
all people ... make a solution that fits for EVERYONE.

But that would (on the other hand) cause way more confusion if you're
working with different projects (using Sebastian Bergmanns example)
... one implementing this the way we would implement "Strict type
hinting" - because that's what he wants ... and another one is
implementing it as "Casting weak type hinting" ... and so on.

I know that the user still has to add some code, but I don't like the
fact to have additional type-hinting that's just doing nothing - and
the user is then adding it if he wants.

I'm still for the 3rd solution as it is most likely the current
type-hint and is not that strict as the first solution. Just to have
it consistent.
What I like most here: All parameters that can be converted to the
wanted format without loosing something are accepted, all other will
stop the execution of the script.

Bye
Simon