> 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.