> 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; }
>
That's black and white thinking. Casting is obviously too forgiving (a cast
literally accepts ANYTHING), and there were specific problems identified with
that syntax that have absolutely nothing to do with whether you can juggle
parameter types.
Current sentiment seems to be settling around behavior similar to the internal
zend_parse_parameters, which is to say:
(function(int){})('1'); // no error
(function(int){})('123xyz'); // E_NOTICE, function gets (int)1
(function(int){})('xyz'); // E_WARNING, function gets (int)0
Someone (you?) made a good case for questioning these warning levels, but the
basic concept of what to accept and what to warn about is good, and already in
use (which makes it far easier to accept).
> 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.
>
Array behaves as it always has (E_RECOVERABLE_ERROR if you don't pass an
array). Scalar types don't implicitly convert ("juggle") to arrays, so there's
no issue there. There's no reason to attempt to support any implicit conversion
from array to string either. E_RECOVERABLE_ERROR would be perfectly appropriate
here (or you could argue to raise E_WARNING, which is technically what
zend_parse_parameters does).
> 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.
>
Look back at the discussion and arguments. The string input thing comes up over
and over again. Resisting this point simply caused frustration and ultimately
turned into a consistent battle cry of "we're never going to add strict typing
because it breaks the language and virally affects all the code up the chain".
The input parameters became a poster child case, but conceptually if you make
this too strict it virally forces everything up the stack to behave strictly as
well (hence the frequent arguments, "it will break the language", and "it would
no longer be PHP".)
You can disagree, that's totally fine, but *this* discussion assumes that a
successful proposal must take the opposite route, and fully embrace string
inputs and limited type juggling.
> 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.
I'd use it liberally, especially in models, but not universally by a long shot.
Type hints aren't designed to make life easier for the caller (though they
should avoid making it harder). Type hints are connected to the algorithm of
the function itself; they offer a logical guarantee to the function that the
types of the parameters are consistent with the nature of the algorithm. For
example, an add() function needs to be able to trust that parameters will be
numeric, substr needs to be able to trust that parameters will be a string + an
integral value, and so on.
If the logic requires this simple assurance, I'll use a hint. If not, I won't.
> 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).
>
The current hints consist only of arrays and classes. These *can't* be user
inputs (well, arrays can, but really, that's so rare for someone to actually
use.) Checked or unchecked is basically irrelevant, because these parameters
could never have originated as user data anyway. Strings, integers, numbers,
values used in boolean checks, these all can and will originate as user data,
which is the concern raised over and over in the past. This is a fair argument.
One can argue that people shouldn't have written their code that way, but they
will, and do, and it "works". Continuing to behave reasonably in these cases
has been important to the core devs in the past. Assurances that we'll support
this case have been incredibly effective so far in calming frustrated people
jumping into the middle of this discussion.
> 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.
I think we all mostly agree on this point. Reserving these and other keywords
isn't going to be a major hangup.
John Crenshaw
Priacta, Inc.
