Hi! > That's only a problem if you frame the new hints as "a type of implicit > cast". If they were to be described in relation to existing > functionality, I'd describe them as a new type of *explicit* cast, but
How they are explicit cast if you're not explicitly casing anything? > as mentioned elsewhere, I'd be happy for them to exist outside of > function signatures too as a new notion of "strict cast". That's exactly what I want to avoid - having several forms of casts with different rules. One is good, two is kind of OK, three is too much. Especially as you won't even know which rules something as simple as foo($bar) would invoke. > That way, we remove the expectation that they will act the same as some > other feature, and can simply evaluate their usefulness as a new, > separate, feature. It's not a new, separate feature. It can not be separate from what already exists in the language. That's the whole point of it - not concentrating on one use case but looking how it sits together with the rest of the language. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
