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: signature.asc
Description: OpenPGP digital signature

Reply via email to