> Consider the following signature:
>
>     function foo(int $bar) {}
>
> In the case of a *string* representation of a hexadecimal number, the
> following would error only on the last iteration with a weak hint, and on
> the
> very first if it was a strict hint:
>
>     for ($i = 0; $i < 11; $i++)
>     {
>         foo(base_convert($i, 10, 16));
>     }
>
> And when I said leading zeros, I was talking about fixed-length string
> identifiers such as '001', '002', etc. where you may *unintentionally*
> pass
> such a value to a function that deals with ... quantities, for example. A
> strict
> hint in that case would immediately catch this logical error while a weak
> hint
> would silently ignore the leading zeros and will happily treat the value
> as an
> integer. Again, the precondition here is that it's not an integer value
> that
> happens to be stored as a string, but a non-integer value that just looks
> like
> an integer.

Thanks the example Andrey, it's helpful.

My goal with asking for these use cases isn't to claim that they never
exist, and I certainly don't want to get into a theological discussion.  My
goal is to try and figure out whether many, if not all, proponents of strict
typing would be willing to live with a compromise on single set of rules,
that on one hand would be a lot stricter than what was proposed for weak
typing in the v0.3 RFC (bool->anything fails, any string that's not strictly
looking like a number incl. "100 dogs" -> int/float fails, float->int
fails), but on the other hand, would allow certain lossless conversions
(numeric string -> int/float, int->float, toString() to string, etc.) to
work.

When people from both schools of thought (strict/weak) come to evaluate this
possibility, remember that we don't need a solution that works in 100.0% of
the cases.  Edge cases, again, be them strict or weak, can always be
implemented with a bit of custom code inside the function - the important
thing is to get a system that addresses the vast majority of cases.

Thanks!

Zeev

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

Reply via email to