On 4/19/2016 8:48 PM, Zeev Suraski wrote: >> but it does not help with primitive types. :( > > Which is fine. Primitive types can and should get dedicated solutions. > There's really no need for allowing over creativity with userland-customized > scalar types. >
Hmmm... nope. I already brought various examples where I personally see the strength of union types and that is exactly with the primitives.[1] *int|string* is so powerful if you deal with MySQLi and its BIGINT stuff because I can fully type hint it now (like the /mysqli/ extension does in C) and check very fast if I need to use GMP or not. I can only repeat. I am fully supporting to block union types if we instead commit to the introduction of additional primitive types (as outlined in the generics RFC)[2] and operator overloading in userland. However, use cases remain and union/intersection types can help especially if you do not want any kind of is-a relationship in your classes. In other words, we do not want to introduce an additional interface for something because we do not want the instance to pass through other checks. Or, of course, the situation where it is simply impossible for me to introduce the interface: built-in classes. I might want to decorate them and pass through all checks but I cannot because, well, how? [1] http://marc.info/?l=php-internals&m=146080503103988&w=2 [2] https://wiki.php.net/rfc/generics#related_enhancements > I believe you think I meant that instead of checking that $b's class actually > implements foo and bar, we'd check whether $b has all of the methods needed > by foo and bar - which means that theoretically means that it may have > methods foo() and bar() but not actually 'officially' implement their > respective interfaces. But there's no reason to do it this way and that's > not what I meant. > Instead, with my proposal, a $b object whose class implements both foo and > bar - will automatically be accepted as one that also implements baz. The > checks will be conducted at the interface level, not the function list level. > In other words, if $b doesn't explicitly implement baz, we'd take a look at > 'baz', see it's comprised of foo & bar, and check whether $b's class > implements them. > > At this point, I can't imagine any negative side effect to automatically > deducing that an object that implements foo and bar also implements baz > (other than a small performance hit, probably roughly the same as the AND > union type). Like I mentioned in my original post, I don't necessarily think > it's needed - I personally see no reason not to add 'baz' to the list of > interfaces impl implements, or as you said, replace foo and bar with baz > altogether. > interface HouseCat { function drink(); } interface Dog { function eat(); } interface Lion { function drink(); function eat(); } A lion drinks and eats but is neither a HouseCat nor a Dog. This is dangerous and introduces many potential hard to find bugs. Better don't touch it and go for duck typing or the introduction of a dedicated interface: *always* -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
