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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to