I can't see the difference between your proposal and the conclusion I
reached yesterday?
(which was that there is a near consensus around strict checks by
default, with casts allowed with some syntax).
Well to me it Sounded like you wanted to Rely on Standard Type juggling
and what i am proposing is more strict than that. More over i am Not
convinced that strict should Be the Default.
Regards,
Lukas
Just wanted to note the weak string check is the same as the strict one in
the RFC since it appears to be incomplete. It should encompass any type that
can cast to a string. That includes any scalar, and also objects with
__toString method.
Also if this will be introduced, it needs to account for mixed type
arguments, such as null/bool/int or null/numeric etc. The RFC doesn't
mention null at all leaving me to assume null is always allowed, no matter
what.
I'm a supporter of strict typing for languages in general, however, in *PHP*
in particular, strict checks don't make sense to me, given its current
behavior.
This is a language where summing up an integer and a string can result in a
float. API authors will start assuming strictness from their clients that is
hard to achieve, and in the end result in peppering function/method calls
with explicit type casting on each argument. We do not want that, I suppose.
There is one type of check that can be added right now, however, while this
discussion continues:
function add_user(scalar name, scalar phone_number, scalar age) {}
I think we can all agree, if we can check for a class and array, then
checking for a scalar is a natural constraint. It's both strict and weak at
the same time since it's generic enough not to need that separation. Scalar
here is defined by the same rules as is_scalar(), but also allows null as a
passed value to be consistent with the other check types.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
