> 1. Do we support complex types combining unions with intersections?
We can do it at any time, so we should not hurry with this.
If we think about why people would like to do such complex types -
probably it is because PHP currently doesn't support methods overloading.
Thus we'd rather introduce methods overloading than complex union
structures, but with yet that is a different topic.
> 2. Do we also bring in type aliasing?
Think that would be great (class can define some types, which it uses, so
that client code can type-hint it):
```php
class Foo
{
public type Collection = Countable & Traversable;
public function doThisAndThat(self::Collection $collection)
{
// ...
}
}
class Bar
{
public function delegateToFoo(Foo::Collection $collection)
{
$this->foo->doThisAndThat($collection);
}
}
```
But, as Larry told, it should be a different RFC.
> 3. How does this intersect (pun!) with coercion when strict_types=0 ?
If we don't introduce complex structures (I hope), it should work the same
way independently of whether strict_types is 0 or 1.
> 4. Should we be considering other bloat^W features?
Not really. There should be some case where such features are actually
needed.
Regards, Eugene
On Sat, Nov 7, 2020 at 10:47 PM Sara Golemon <poll...@php.net> wrote:
> On Sat, Nov 7, 2020 at 9:33 AM Olle Härstedt <olleharst...@gmail.com>
> wrote:
>
>> 2020-11-07 15:12 GMT, Eugene Sidelnyk <zsidel...@gmail.com>:
>> > function foo(A & B & E $object) {
>> > // some work
>> > var_dump($object);
>> > }
>> >
>>
>> You mean intersections? Psalm supports this notation.
>>
>>
> IIRC we discussed intersection data types when union types were on the
> table and we settled on a "take it slow" position. That said, union types
> are... **checks notes**... oh, wow. Actually still pretty new (introduced
> in 8.0).
>
> My conservative side wants to wait and see what the community does with
> unions, but if static analyzers are already providing this functionality,
> then maybe the community has already made its position known.
>
> Questions to answer in any RFC on this topic:
> 1. Do we support complex types combining unions with intersections?
> e.g. function foo(((countable&traversable) |
> (stringable|jsonserializable)) $obj) { ... }
> Pros: Super descriptive
> Cons: Super ugly
> My opinion: Maybe, but not immediately. Let simple unions/intersections
> bake for a version or two.
>
> 2. Do we also bring in type alliasing?
> e.g.
> type CountableTraversable = Countable & Traversable;
> type AllTheSerializations = Stringable & JSONSerializable;
> function foo(CountableTraversable | AllTheSerializations $obj) { ... }
> Pros: Can make a given code base more readable once you know the types
> Cons: Can make figuring out types in a new codebase harder.
> My opinion: Yes. Sooner the better.
>
> 3. How does this intersect (pun!) with coersion when strict_types=0 ?
> Initial thoughts: Probably very poorly.
>
> 4. Should we be considering other bloat^W features?
> a. Exclusive Union: type SingleSerialization = Stringable ^
> JSONSerializable; // XOR: Must be one, but not both
> b. Blacklist: type AnythingButDOM = !DOMElement;
> My opinion: Hell no. Just spitballin'.
>
> -Sara
>
>
