Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58100
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
Received-SPF: pass (google.com: domain of arvids.godjuks@gmail.com designates 10.180.95.105 as permitted sender) client-ip=10.180.95.105;
MIME-Version: 1.0
In-Reply-To: <CAGsnKxa+qqJqy++4pCTrnU1nG_Nf59TyTCpvaQtZSNTu-Byr5w@mail.gmail.com>
References: <CAG=uTXFQUY=EDb=ut97nNSm+m8sMQNRK-9YPcfb2quaoS246-g@mail.gmail.com>
	<CAO8n+WJrqUguS4FSq==z9rF6iLoz3uXqSLBrrkY6yMBY9DrTWA@mail.gmail.com>
	<CALtuQzD6f_vcZiGi2HWdP8SSqf9744FucUC+4sX7PnGhOnh+rg@mail.gmail.com>
	<4F455C96.50706@gmail.com>
	<4F455E91.2060408@alliantinternet.com>
	<028001ccf1ab$0b200050$216000f0$@alliantinternet.com>
	<4F457517.7050901@alliantinternet.com>
	<028d01ccf230$91d79b00$b586d100$@alliantinternet.com>
	<CAAyV7nHA_DhyZUqU2=EYDSvCEYmc7MFejsG97dXCoTtaeMurMg@mail.gmail.com>
	<4F4686C6.2040207@sugarcrm.com>
	<CAKOpQSwtHvSoSVj8q4_QTte42D588OUBDBQ_a4YB8q=GquekBQ@mail.gmail.com>
	<fe9c203ff43ec075a6f1a405053889ec.squirrel@www.l-i-e.com>
	<CAKOpQSwqddd1YUeuTGOQWX+V9SA_is-2UE1TOXfqt1YQoz2upw@mail.gmail.com>
	<CAG=uTXGTCxaEEOdt7cz81DT7vOOvMm1P0jdrgMX0CpY4e86t+Q@mail.gmail.com>
	<CAKOpQSy7r063FuoXpAy_7nsaBpz08LrVnz0zpa6CDF7fF-Tu6g@mail.gmail.com>
	<4F496818.8000405@sugarcrm.com>
	<CAKOpQSyewRGH8nZhXAZf9+hh1pU1oNGfZCn5rbfPW8Ydy9aH9g@mail.gmail.com>
	<4F4982BF.8090102@sugarcrm.com>
	<CAKOpQSwo0xy4tyZQW6zZGeuZgqCEGEqUpbD=iAWfa4TkaeeqrQ@mail.gmail.com>
	<CAL0xaBFwbmamuNCuakxv9jf2LXQQ4ej4RvFRm_UBD460Sazprg@mail.gmail.com>
	<CAKOpQSyi2Cpr=rYaWkkJZtyjcDzLVqr5QNUzLza1RQ9q27fA+A@mail.gmail.com>
	<CAGsnKxa+qqJqy++4pCTrnU1nG_Nf59TyTCpvaQtZSNTu-Byr5w@mail.gmail.com>
Date: Mon, 27 Feb 2012 02:09:45 +0200
Message-ID: <CAL0xaBEWmYYH9D7BEpUVEbGgSoP5QPWir8Qo+S4hz+CR53jdxA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d0442816a830cc204b9e6ede8
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--f46d0442816a830cc204b9e6ede8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I absolutely agree with this. The hurdle with the strict type hinting is
pictured very well. Strict is strict - either the whole codebase follows
it, or it doesn't follow it at all. If a part of the code uses it - means
all the code comunicating with that part has to use, or at least has to be
written with the strict type hinting in mind.

Oh, and i remembered a case where strict type hinting would be highly
questionable - the "mixed" variant. Right now we document thouse with the
phpdoc comments, but its quite common use in php to accept a null or an
array for example. I can't imagine strict type hinting in this case, but
weak type hints can work.
27.02.2012 0:51 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=
=B5=D0=BB=D1=8C "John LeSueur" <john.lesueur@gmail.com>
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> [trim]
>
>> 2. "Strict type hinting would eliminate PHP's flexibility and take away
>> its
>> unique simplicity."
>>
>> I respectfully disagree.  Again, let me remind you that we are *not*
>> talking
>> about *converting *PHP to strict type hinting.  Instead, we're merely
>> talking about allowing PHP developers to *choose* whether or not to make=
 a
>> given function use dynamic or strict type hinting.  The default behavior
>> will remain dynamic, just as it is now.  But there are situations where
>> strict type hinting, even in a PHP script, would make more sense.  There
>> are many PHP developers, myself among them, who see considerable benefit
>> in
>> being able to make a function more condensed and streamlined without
>> having
>> to waste so much time on sanity checks that could instead be handled at =
a
>> lower level in the core.
>>
>>
> So this is the argument that those who object to strict type hinting don'=
t
> agree with. Take the following:
>
> function strictTypes(/*int*/ $var)
> {
>     //this is what the engine does if we have strict type checking
>     if(!is_int($var)) trigger_error();
> }
>
> function weakTypes(/*int*/ $var)
> {
>     //this is what the engine does if we have weak type hinting, or
> something similar.
>     if(!is_numeric($var) || (int)$var !=3D $var) trigger_error();
>     else $var =3D (int)$var;
> }
>
> function dynamicTypes($var)
> {
>     strictTypes((int) $var);
>     //if $var is not an int, we just made it 0, and hid the type error.
>     //to avoid this mistake we have to do:
>     strictTypes(is_int($var) ? $var : ((is_numeric($var) && (int)$var =3D=
=3D
> $var) ? (int)$var : trigger_error());
>     //or something like it.
>     weakTypes($var);
>     //we'll get an error if $var can't be converted to an int without dat=
a
> loss.
> }
>
> By calling the strictTypes() function, the dynamicTypes() function
> inherits the problem of validating the type of $var. Well, if I'm writing
> the dynamicTypes function, I don't want that work, so I push it up the
> chain, and change my dynamicTypes function to statically typed. If you're
> into static types, then you say, that's great, someone should make sure
> that $var has the right type when they got it from the user. But if you'r=
e
> not into static types, you were just forced to do type checking, either i=
n
> your code, or passing it up the call chain for someone else to do the typ=
e
> checking. That's what is meant when we say dynamic typing can't really
> coexist with strict typing. For those into dynamic types, weak type hinti=
ng
> is much more palatable, because it doesn't require callers to adopt the
> same philosophy.
>
> If you want type hinting, you'll have to specify which kind you want,
> strict or weak. If it's strict type hinting, you'll need to convince even
> those who think dynamic typing is a guiding principle of PHP that it can =
be
> done without forcing strict typing up the call chain. Weak type hinting i=
s
> a softer sell, but requires a lot of thought(much of which has been done,
> if you look in previous discussions) , about how and when to convert valu=
es.
>

--f46d0442816a830cc204b9e6ede8--