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
