Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58101
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.180.24.4 as permitted sender) client-ip=10.180.24.4;
MIME-Version: 1.0
In-Reply-To: <CAL0xaBEWmYYH9D7BEpUVEbGgSoP5QPWir8Qo+S4hz+CR53jdxA@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>
	<CAL0xaBEWmYYH9D7BEpUVEbGgSoP5QPWir8Qo+S4hz+CR53jdxA@mail.gmail.com>
Date: Sun, 26 Feb 2012 16:30:26 -0800
Message-ID: <CAKOpQSxmqWUbU-6_aS825mMwpNztHjiQy8WrZ-tJ6jUyhHSYRg@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d043be1c6823c7904b9e73766
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)
From: kris.craig@gmail.com (Kris Craig)

--f46d043be1c6823c7904b9e73766
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I actually agree as well.  Looking back in the thread, I think my overly
broad use of the word "strict" might have led to some confusion over what
I'm advocating.  So to clarify, I'm referring to optional non-dynamic
typing vs purely dynamic typing as we have now.  Strict typing would
require some global or config setting as I originally proposed; a
function-by-function approach obviously would only work with weak typing.
 Looks like I got a bit dyslexic on you guys so I apologize for the
confusion.

That being said, I do believe that optional strict typing on a global scale
is worthy of further discussion, though I remain on the fence as far as
whether or not we should actually go forward with that idea.  But the
function-by-function approach (by which I mean weak typing lol) is
something that I'm increasingly convinced is a good idea.


--Kris


On Sun, Feb 26, 2012 at 4:09 PM, Arvids Godjuks <arvids.godjuks@gmail.com>w=
rote:

> 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 b=
e
> 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 awa=
y
> >> 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 behavi=
or
> >> will remain dynamic, just as it is now.  But there are situations wher=
e
> >> strict type hinting, even in a PHP script, would make more sense.  The=
re
> >> are many PHP developers, myself among them, who see considerable benef=
it
> >> 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 a=
t
> 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
> data
> > loss.
> > }
> >
> > By calling the strictTypes() function, the dynamicTypes() function
> > inherits the problem of validating the type of $var. Well, if I'm writi=
ng
> > 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're
> > not into static types, you were just forced to do type checking, either
> in
> > your code, or passing it up the call chain for someone else to do the
> type
> > 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
> hinting
> > 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 ev=
en
> > those who think dynamic typing is a guiding principle of PHP that it ca=
n
> be
> > done without forcing strict typing up the call chain. Weak type hinting
> is
> > a softer sell, but requires a lot of thought(much of which has been don=
e,
> > if you look in previous discussions) , about how and when to convert
> values.
> >
>

--f46d043be1c6823c7904b9e73766--