On 15 August 2012 18:15, Nikita Popov <nikita....@gmail.com> wrote: > As already pointed out repeatedly, argument typehints serve the > purpose of defining an interface. No, they are not required to run the > code, that's true. But they still serve an important purpose for > object oriented programming (and, just to make sure that you don't > miss it again: That purpose is defining the interface). Variable > typehints do not, as far as I can see.
I was most of the way through writing a much longer e-mail responding to the original post, but you and Stas have summed it up well, really. Type hints actually have a use in the object model of PHP in terms of interface definition. The only uses I can see for these variable hints are: 1. An informative use for IDEs, as previously noted, which is already filled adequately by @var documentation. 2. An assertive use in development: effectively, a different way of writing assert($var instanceof ClassName) to verify your assumptions on variable types. Personally, I don't think either of those justify the addition of the feature. The thing is that even ignoring type hints' interface definition functionality and treating them as pure syntactic sugar, type hints have another benefit: if you have several parameters to a function, type hints allow you to verify their classes in one hit, rather than having to make several calls to a verification function or implement something like zpp for objects in userspace. That leads to neater, shorter code. This feature doesn't have that quality: you can only hint one variable at a time, so there's not even a significant saving in time/typing for the developer between (to pick the only version of the syntax I don't find completely objectionable) "ClassName $var = $object;" and "$var = isType($object, 'ClassName');". In summary, I guess I'm -1 on the feature, and -10⁹ on any version of the feature that looks like a typecast. :) Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php