Hi,
On 07/16/2014 10:45 PM, Andrea Faulds wrote:
On 16 Jul 2014, at 21:43, Zeev Suraski <z...@zend.com> wrote:
anything this RFC permits will
be permitted by zpp, it's the reverse that isn't necessarily true.
Right, so it needs to be fixed. It makes no sense to force a new agenda
on the language that's inconsistent with the rest of the language. Align
your new feature to the rest of the language, not the other way around.
But to do so would be to make the feature less useful, nor satisfy people who
want stricter hinting.
tl;dr:
- I'd like to have E_CAST on all castings/type jugglings even if we do
not get scalar type hinting.
- I propose to say/implement "scalar parameter casting" instead of
"scalar type hinting" with a casting syntax:
function foo( (int) $i, ...)
That way we lower expectations, explain the different syntax/semantics
in contrast to hints, give a hint what scalar parameter casting does,
and I see the use-cases of both parties fulfilled.
-------
I didn't follow the complete thread in detail. And I have to confess
that I'm a big fan of strictly "defining types of parameters", because I
see how it could help me in my work.
BUT: As I see it, E_CAST (with the existing type juggling rules/casts)
plus "scalar parameter casting" is the best compromise in the
spirit/history of PHP without BC breaks and I think all use-cases are
satisfied:
- E_CAST notifies me about data loss on type juggling.
- "scalar parameter casting" should just be a convenience for coding:
function foo( (int) $i, (string) $s )
{
}
is the same as:
function foo( $i, $s )
{
$i = (int) $i;
$s = (string) $s;
}
or perhaps better::
$i = (int) $i;
$s = (string) $s;
foo( $i, $s );
That way you decide if you want to be very strict about the data in your
variables or not, and both parties (strict vs. non-strict) can share code:
- With E_CAST you get additional information on data loss on type
juggling and casting in your complete code base. That's a plus for
everybody who's a little bit scary about type juggling in those cases.
- As a fan of strict mode I can develop my applications and libraries in
E_CAST mode via an error handler that throws exceptions on E_CAST. (We
even run our code with E_ALL in production to find edge cases.)
- I see the severity of E_CAST on a level like E_NOTICE and E_STRICT:
Best practice - if others do not understand/care it's their "problem"
but they can use my code like each other code.
- As a fan of non-strict behavior, you can provide a string for a
parameter that is defined to be an integer. If it contains a number you
are happy that my code works as PHP deals with casting. If your string
does not contain a usable value you have to live with the good old PHP
way when you use code with wrong input data and my code treats it as an
integer and you perhaps have some data loss. But that's not the
responsibility of my code - especially if I interpret the casting syntax
as casting the parameters before hitting my method/function. (BTW: I
don't think that casting should be used as sanitizing of user input like
it was proposed/said to be widely used. I prefer validation over
sanitizing.)
- Depending where and how I define my error handler, I do not see that
my code needs to behave differently if E_CAST is enabled or not. I think
you should implement your error_handler for E_CAST in the spirit of
Symfony's debug mode: In debug mode all errors are converted to
exceptions but they are ignored in production mode. I guess you'd never
say: My application behaves differently. Otherwise you probably use
exceptions for control flow. (I do not say that you have to disable
E_CAST for your production mode. But if your code passes all tests in
E_CAST, there is a good chance that it works without E_CAST as well.
Then it's your decision as product owner if you have to break on errors
in edge cases or not.)
- Regarding consistency to array and object hints: Using the casting
syntax/semantics you could even provide (array) and (object) as "scalar
parameter casting" in contrast to the hints. But of course you can argue
that users are confused about "(array)" vs. "array". I could live with
that confusion as people have to learn about "parameter casting" and
that should be explicitly mentioned in the docs/tutorials/blog posts/...
- I don't know if there is a downside for static code analysis. But
probably you even need defined return types for that.
Regards
Thomas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
