On 13/07/2014 17:28, Zeev Suraski wrote:
BTW, auto-converting type hints were
proposed by Lukas and me back in 2010, even though I see them attributed to
Anthony in 2012 :)
Aha, seems like a case of convergent thinking, with the exception that
Anthony proposed using distinct syntax to represent the casts (the wiki
isn't rendering properly for me, so apologies if that is also covered in
your older proposal).
As I've mentioned elsewhere, having the same syntax mean "assert" for
scalars but "cast" for non-scalars leads to an ambiguity with arrays,
for which both actions are available (and current code performs an
assertion).
The next section is about "casting weak type hinting", which is described
as
"one of the more interesting proposals". It certainly has merit, although
in my
opinion it's less powerful than the other options in what it adds to the
language, as the equivalent userland boilerplate is really minimal (e.g.
$foo =
(int)$foo).
That's not a bad thing in my book - another way to describe it is that it's
consistent with the rest of the language and doesn't require developers to
learn another new set of 'similar, but different' semantics.
In terms of value that it does bring to the table, it gives you a standard
way to do something that's very common in a shorter way and increases
quality of APIs (it's much more likely people will use this to describe
their APIs than docblocks), and we can use better warning semantics than we
currently have on conversions (without changing the rules), and it allows
you to do all that without having to add tons of defensive code (in the
calling code) that is often unnecessary. Making it easy to implement means
it'll get used more - and so far I fail to see what we stand to lose (more
on that below).
I think a lot of this hinges on the next question, of whether the
warning semantics are inherently tied to this new syntax, or a separate
issue.
To me, it makes perfect sense for the following to be equivalent, with
one just a more expressive way of writing it:
function casts_as_array($foo) { $foo = (array)$foo; /* ... */ }
function casts_as_array((array)$foo) { /* ... */ }
As I've mentioned elsewhere, and indeed was mentioned in Anthony's
proposal at the time [2], the addition of warnings on lossy casts is a
completely
separate issue to the ability to sugar those casts into a function
signature.
I don't see why they would be separate, especially if the key reason for
going for 'option #3' is that it helps find bugs better. Option #1 with the
added logic of warning about lost data or 'bogus' conversions has all the
advantages of option #3 but also other advantages.
Other than isolating the change for backwards compatibility, I don't see
a big reason to treat them as separate. If the aim is to make the scalar
type hints "just like an existing cast", then lossy casts should work
the same way in both places.
On the other hand, if the aim is to make it easier to detect lossy
casts, then a way to do that *outside* function signatures is just as
useful as a way embedded in them.
In fact, thinking about it, several of these proposals add implicit
functionality in the function signature which would remain tricky in
userland code. Current type-hinting does not do this (it can be emulated
fairly easily with is_array(), is_callable(), and instanceof).
If we don't want all casts to emit warnings on loss, perhaps a new
function or keyword request them - e.g. (strict int)$foo, or
strict_cast($foo, 'int').
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
