Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58164
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
Received-SPF: pass (google.com: domain of ircmaxell@gmail.com designates 10.224.72.138 as permitted sender) client-ip=10.224.72.138;
MIME-Version: 1.0
In-Reply-To: <CAH-PCH6Bre5yzc6r3zxEj3=zZY0PHDOCVQ0s=f8JBDSPnK+5Fw@mail.gmail.com>
References: <CAG=uTXEfTBqX7n0_zfGjB_txQFKtZXF4MOo6RHHPSRPerGeKZA@mail.gmail.com>
	<CAKOpQSwP_VXazO1WgQgOWiKTmgiwzorg2=ii+Mdz58a=TKs6VA@mail.gmail.com>
	<CAGovj_O5UQx9aAaYg302i-kKp13CtBKNLmQ48OLHNvk61rM1sw@mail.gmail.com>
	<1330357150.2159.30.camel@guybrush>
	<CAGovj_MUt60EJfG8a7r-cqrC2PKsi8mqh6v_iyNoRDq8q-jh2Q@mail.gmail.com>
	<CAH-PCH6Bre5yzc6r3zxEj3=zZY0PHDOCVQ0s=f8JBDSPnK+5Fw@mail.gmail.com>
Date: Mon, 27 Feb 2012 12:38:10 -0500
Message-ID: <CAAyV7nFmfhb97CGAK1ZAkp9qb3oCPxbUDnS-Z-v3cP2APcYs=g@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Michael Morris <dmgx.michael@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Scalar type hinting
From: ircmaxell@gmail.com (Anthony Ferrara)

> no, it is: "come back after you did your homework, and you can provide ne=
w
> arguments to the discussion"


To be completely fair, I did homework on this.  I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=3Dphp-internals&w=3D2&r=3D13&s=3Dstrict+typing&q=
=3Db
and a bunch of the posts on
http://marc.info/?l=3Dphp-internals&w=3D2&r=3D54&s=3Dtype+hinting&q=3Db

The vast majority of what I found were quite good arguments for
including the feature.  I found quite a bit of "this was discussed to
death, do your homework and provide new arguments".  What's odd, is
that one of the earliest on-topic threads that I found (2007:
http://marc.info/?l=3Dphp-internals&m=3D119514660125258&w=3D2 ) had this as
the third reply.  The only on-topic discussion that I found prior to
that was in 2006 (almost exactly 1 year prior:
http://marc.info/?l=3Dphp-internals&m=3D116257685415135&w=3D2 ).

Discussed to death.  Yet only one time before (discussing a specific patch)=
...

And the opponents still said no...

There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring.  However, there were also
solutions proposed to nearly each and every one of them.

And the opponents still said no...

It has been brought up time and time again.  Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...

And the opponents instead said "this has been discussed to death, no"...

Please can you stop saying "this has been discussed to death".  To be
frank, don't stop the discussion because you don't like the idea.  It
has been discussed to death.  But the discussion has only really ever
involved people who are for it.  The opponents by and large have used
two arguments: "It has been discussed already, so no" and "don't make
PHP into Java".

There has been some discussion of technical merit and problem
resolution by opponents, but finding it is VERY difficult among all
the down trodding commentary.

So let me make a plea:

If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so!  If you don't like the feature, and are
going to lean on "It's not Java", or "We've discussed this to death
already", please don't...



And to be fair: "and you can provide new arguments to the discussion"
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.


Anthony


On Mon, Feb 27, 2012 at 11:55 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris <dmgx.michael@gmail.com>w=
rote:
>
>> So the official response is "get lost"?
>>
>>
> no, it is: "come back after you did your homework, and you can provide ne=
w
> arguments to the discussion"
>
>
>
>> I don't know about the internals implications. =A0But from an external
>> API standpoint I see no problem in allowing programmers who want to
>> strictly enforce a variable's datatype to do so. =A0Legacy code would
>> not be affected unless it was trying to use the new reserved word
>> "strict"
>>
>>
> it was discussed before, strict typing tends to be "viral", in the sense
> that the developer using a lib which enforces method signatures using typ=
e
> hinting can either:
> - write a lot of boiler plate code to make sure that he/she is passing th=
e
> expected types (notice that strict typing would pass that burden to the a=
pi
> consumer, which is against the Generous on input, strict on output
> paradigm, plus it would generate much more work, as there are always more
> consumers than producers)
> - or simply passing those requirements up in the call chain, which is les=
s
> work, but affects even more code, and in the end, turns the whole app int=
o
> strict typing.
>
> --
> Ferenc Kov=E1cs
> @Tyr43l - http://tyrael.hu