Exactly, hence why I'm still on the fence with that. I was hoping for some
further discussion though to see if anyone can think of a way around that,
though admittedly nothing comes to my mind.
--Kris
2012/2/26 Tom Boutell <t...@punkave.com>
> There's no such thing as optional global anything, if you're a library
> or framework developer who has to cope with what's turned on wherever
> their code may wind up.
>
> On Sun, Feb 26, 2012 at 7:30 PM, Kris Craig <kris.cr...@gmail.com> wrote:
> > 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.godj...@gmail.com>wrote:
> >
> >> 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 пользователь "John LeSueur" <john.lesu...@gmail.com>
> >> написал:
> >>
> >> > [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 != $var) trigger_error();
> >> > else $var = (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
> ==
> >> > $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
> 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'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
> 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
> >> is
> >> > 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
> >> values.
> >> >
> >>
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
