On Sat, Nov 7, 2020, at 2:47 PM, Sara Golemon 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.
I would be very in favor of intersection types. It's not really useful for
primitives, but with interfaces it becomes quite handy.
> 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.
I'd favor a type being exclusively unions or intersections. No mixing, with
the possible exception of allowing the type to be nullable. So Foo & Bar is
OK, Bar | Baz is OK, but Foo & Bar | Baz is just more complex than any
reasonable person should be doing.
> 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.
This is a separate RFC from intersection types and should be submitted
separately. That said, yes please!
> 3. How does this intersect (pun!) with coersion when strict_types=0 ?
> Initial thoughts: Probably very poorly.
I'm unclear how/why it would? Please explain?
> 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
Hard pass. At that point, make separate methods.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
