On Wed, Aug 15, 2012 at 10:06 AM, Stan Vass <sv_for...@fmethod.com> wrote:
I'd like to also ask people to read what the intended effect of the
proposal
is instead of going into abstract discussions about how casting one class
to
another doesn't make sense (this is not what's being proposed).
I think you confused everyone by a) having "typecasting" in the title
and b) starting with the (Foo) casting syntax (so everyone assumed
that you indeed want some kind of class casts, whatever that may be).
I had "typecasting / typehinting" in the title, and I'd like to remind
everyone again that in dynamically typed languages class casts are often
implemented as a basic validation operation, consistent with what I
proposed.
Regarding the actual proposal, could you maybe clarify the use-cases
for this? I can see that it could be useful in principle, but your
actually named use cases confuse me somewhat. In particular, I don't
see how this would help dependency injection containers. I can see
that it helps service locators and registries, but both of those are
considered antipatterns, so there is no reason to add additional
language features for them. DICs are only used to inject top-level
dependencies, so in that case types should be fairly well covered by
parameter type hints.
Two use cases apart from registries: PHP has no typed iteration and arrays,
so you the only way to guarantee (and the IDE to know) the type of a
variable in these cases is a hint:
Foo $bar = $array[1];
foreach ($array as Foo $item) { ... }
Automatically this applies to everything that uses ArrayAccess as a
shorthand too, and properties of anonymous objects (stdClass).
The current alternative is peppering code with pseudo-PHPDoc inline hints,
and instanceof assertions which truly is a facility the language core should
provide, instead of us emulating it.
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
