Re: Re: Improving PHP's type system

On 4/19/2016 10:19 PM, Zeev Suraski wrote: > I can only repeat - primitive types can and should get dedicated solutions. There's > really no need for allowing over creativity with userland-customized scalar types. If we think that > a certain scalar definition makes a lot of sense, we can add it at the language level. There's > no need to complicate the language, add syntax which makes no sense for objects and isn't > really needed for scalars either. > We can for many: type number := int|float type object := <any object> type scalar := bool|int|float|string .. However, what about: type ? := array|Traversable type ? := int|string type ? := float|string type ? := bool|null .. I actually argue that we do not even want to define them on a language level (with the exception of array|Traversable) because these combinations are too usecase specific. >> interface HouseCat { >> function drink(); >> } >> >> interface Dog { >> function eat(); >> } >> >> -interface Lion { >> +interface Lion extends HouseCat, Dog{ >> function drink(); >> function eat(); >> } > > Pardon me saying this but it doesn't appear as if you've read what I wrote. Please > take a look at the 'diff' I made in the definition of your Lion class, because without it, > your sample and mine have little to do with each other. > > With that change in place, please reevaluate whether what you said is relevant: > I guess I just jumped over that fact and misinterpreted it because what you are proposing is a magic intersection type limited to interfaces. While I cannot think of a situation where this creates problems from a technical point of view (it is duck typing after all) I find it highly, highly unusual and way too magic as well as even confusing. I think there are two ways: - No union/intersection at all! + Union and intersection! Going somewhere in between destroys generics, bounded quantification, and F-bounded quantification in the future or at least makes it harder to implement cleanly. You need to consider that this RFC might be voted negative but it might come back in PHP 8 or PHP 9 where the landscape has changed so vastly that it might become a yes. Let's not introduce half backed features that nobody ever implemented and found useful in any context or we end up with more weirdness that we already have a some points. -- Richard "Fleshgrinder" Fussenegger

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc