2012/3/8 John Crenshaw <johncrens...@priacta.com>:
> From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
>> That's why I described the rules when type juggling comes into play.
>> If you send a string number, it is converted from string to number by the
>> type hint. If you send a string of characters and pass it to a int type
>> hinted function - sorry, but it's you who shout yourself with a shotgun, not
>> someone else.
>
> If you are determined to have it this way and cannot yield, then you are off
> topic. This thread was built around the explicit premise that any scalar type
> hint MUST be more forgiving than that, and if we take that away there's quite
> literally nothing more to talk about. Regardless of how anyone feels about
> it, the core devs will never accept what you are insisting on above. (If you
> want proof, look at the prior debates on this issue.) This discussion has no
> purpose unless it can actually accomplish something meaningful, so it started
> by accepting this as a fundamental requirement. Allowing strings to be
> implicitly converted to lower types when possible, regardless of whether the
> reason offends your sense of how code should have been written, is a vital
> compromise in the process of improving the typing in PHP.
>
> John Crenshaw
> Priacta, Inc.
Well, if your type hints gets more forgiving, than it's the same that
was proposed by this
function a((int) $arg) {}
And in this case hints have no meaning at all - it's just other syntax
to do the conversion that now looks like this
function a($arg) { $arg = (int)$arg; }
And please give an answer to this question: If we make hints forgiving
(like type casting), then what we have to do with current array type
hints - it gives error on anything but arrays? Change it back so it
does a conversion to array? Sorry, but it will make a mess in my code,
because I already use hints for arrays and objects and changing their
behavior is just out of the question.
I do not remember devs explicitly saying that something like I
proposed will not be accepted. They said there will be no strict type
hinting or strict variable typing. And they do not want to add another
syntax for type juggling functionality. So, if only i'm not mistaken,
my idea is somewhere in between and doesn't look weird or
extraordinary. It just adds ability to make arguments of the
function/method be more picky about what they can receive.
Maybe i'm mistaken, but I have a distinct impression that many of the
posters will use type hints all over the place if and when they will
be added and base their ideas on that. Don't get me wrong, but the
auto-casting type hints are really needed only when you really write
all the code with type hints in every function/method you define and
you don't want to do manual conversions all the time.
Maybe this is that case when people tend to get min-max and do not
consider the average use? My average use of currently available type
hints is low in WEB environment and only in internal stuff where user
input doesn't make in unchecked. And I had quite a good use of them in
a console daemon where there is no user input at all (only working
with database).
As to breaking some BC when making keywords such as "string", "int",
"float" - that's what the major releases are for. When you introduce
ANY keyword there is a possibility that someone is using it and it
will break his application. It's a risk, yes. But now days refactoring
instruments are very good and changing class name thought out the
project is no big deal really - just make sure people are informed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
