You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We talked about these during the process of designing unions but didn't prioritize them highly as we didn't see a ton of compelling use cases. If you have some examples that would be helpful. It's certainly doable.
functionmixins<A,B>(base: {new() :A},b: B}) : {new(): A&B}Object.assign<A,B>(a: A,b: B): A&B;Object.assign<A,B,C>(a: A,b: B,c: C): A&B&C;// few more overload I guess and it's okObject.assign<A,B>(a: A, ....B[]): A&B;
Mixins are a good example. We talked about them a bit the other day. I believe we need more than intersection types to model them well though, we specifically talked about what the signature for Object.assign would be, it's more like:
unless we manually write out some number of overloads and just never let you mix in more than x things at a time (which is what your overloads there would do). Perhaps that's an acceptable solution though.
The overloads would hopefully be unnecessary if we had 'rest type parameters' but both could be useful. In any case, mixins are definitely a good example for this, but they're also something we will look at holistically beyond just intersection types given the desired use cases (ex considering what's mentioned in #727 and #311). If there are other examples worth considering specifically for intersection types we should make sure to get those on paper too.
Actually I don't see any other case flow use them to declare function overload, not sure it is really helpful, I guess if we search a bit they could be some special edge case but not that I can think of.
I keep finding uses for intersection types in my code (even before I knew flow has them).
A typical example is an injected dependency in a constructor argument that requires an object implementing several interfaces (the combinations are too many to have dedicated interfaces for every combination) for ex.
var x = new Foo(barObject: Countable & Sortable & Serializable);
I'd really love to see intersection types in TypeScript.
But another approach could be that types with (incompatible) property collisions can't be intersected (type error).
It's a matter of avoiding accidental errors vs. flexibility. I think the default resolution should be an error for now, with an open possibility in the future to explicitly declare you're ok with the collision (so one should override the other).
It's notable that Object.assign, $.extend etc. cannot be usefully described by TS's type system and yet such functions are extremely widely used in real JS code.
TS gives great support to classes. But using classes means following a particular pattern where I have to use this, which can mean a lot of quite radical surgery on thousands of lines of existing JS code. I tried converting a few large modules that way, class-izing them, but it was damn hard work. To avoid that pain as I've adopted TS, I've used $.extend and extra interfaces and casting-I-mean-type-asserting.
interface ICar {
void accellerate(deltaV: number);
}
interface ISteerable {
steer(direction: number): void;
}
// Pure intersection of two types! PLEASE DO NOT MODIFY!!
interface ISteerableCar extends ICar, ISteerable { }
So:
var car = carFactory.makeCar();
var s: ISteerable = {
steer(direction) { ... }
};
var steerableCar = <ISteerableCar>$.extend(car, s);
This pattern is type-safe against changes to both the ICar and ISteerable interfaces: the s object literal will fail to compile if I don't keep it up-to-date with changes to ISteerable.
But it is not safe against independent changes to ISteerableCar. The type assertion in front of $.extend is based purely on trust that future maintainers will read the comment on ISteerableCar and not add methods or further base interfaces.
Classes don't have this problem:
class Car {
accellerate(deltaV: number) { ... }
}
class SteerableCar extends Car {
steer(direction: number) { ... }
}
In JS classes are just syntactic sugar: they don't do anything you couldn't do another way. But in TS classes are magic. They conceal a call to an extend helper that is strongly typed, which we cannot do ourselves in TS.
With intersection types I wouldn't need ISteerableCar with a scare-comment. I'd just say ISteerable&ICar. And with a properly typed Object.assign:
The great thing about JS is that by providing the tools needed to build objects dynamically, it allows library authors to come up with their own solutions to mixins, multiple-inheritance, aspect-oriented cross-cutting concerns and so on. So I'd love to see TS striving to be the compile-time equivalent of that.
This means that the logical building blocks of type relationships (such as intersection) should be regarded as important in-and-of themselves. They allow the type system to express things that can be done at runtime, and so they support library authors who experiment with ways of building objects.
Yes, classes are the ready-to-wear approach. But give library authors the building blocks so they can try other approaches. This is JS's strength - it's not frozen into one classical OO-style. But at the moment TS is rather class-biased. And lots of JS experts love to hate classes...
Where's the evidence for that? Perhaps fairer to say "Lots of small (or legacy) library developers"?
For large-scale application development a class-based approach is the only way. In such a framework, object literals represent the data (while classes represent the business logic). It doesn't pay (in terms of memory, performance and maintainability) to dynamically endow object literals with sophisticated logic as proposed in the example above.
(NB: I don't have any objection to implementing this feature: I only point out that there are good reasons for TypeScript to remain biased towards classes.)
I think the order should not matter, it should throw error if one tries to intersect incompatible field types.
If one really wants to intersect incompatible types there could also be a field removal/complement like in elm-lang's records. If there is intersect, why couldn't there be removal and other set operations, like include only fields in both types.
Complement example:
interface PersonWithAddress {
name: string;
age: number;
address: string
}
interface Person = PersonWithAddress - { address } // Remove field address
// Person is now interface { name: string; age: number; }
Complement could work as well with other interfaces:
interface A {
a: string;
b: number;
}
interface B {
b: number;
c: string;
}
interface C = A - B;
// C is now { a: string; }
With complement in place, it's now possible to use intersection both ways without errors:
interface A {
a: string;
c: string;
}
interface B {
b: string;
c: number
}
type AB = (A - { c }) & B // { a: string; b: string: c: number };
type BA = (B - { c }) & A // { a: string; b: string: c: string };
And it would not cause errors.
P.S. when thinking these as set operations, the word "intersection" is misleading because A intersection B in above example would be empty set! They have nothing in common.
Jari Pennanen (@Ciantic) It's confusing a bit, but it helps to think about intersection of types, not of their members. An intersection of two types is the union of their members, because the resulting intersection then belongs to both types.
In simpler scalar types intersection has more intuitive results, i.e. the intersection of signed and unsigned byte is -128...127 & 0...255 = 0...127. The resulting values belong to both types.
Also I agree order should not matter, identical properties should merge, incompatible ones should error out. That's the only way to ensure the resulting type is truly an intersection belonging to both types.
Duan Yao (@duanyao) It can be modelled properly - but only where it makes sense. It's just that some types cannot intersect because they involve a contradiction. They disagree about the type of some member, in a way that cannot be reconciled. If we make such a request, the compiler is maximally helpful if it rejects it.
Daniel Earwicker (@danielearwicker) Yes, I am aware of the contradiction. But sometimes the contradiction only exists in TS side, not JS side. In these cases we usually use any to bypass TS type checker -- I wonder if there are better options than any.
Daniel Earwicker (@danielearwicker)https://github.com/danielearwicker Yes, I am aware of
the contradiction. But sometimes the contradiction only exists in TS side,
not JS side. In these cases we usually use any to bypass TS type checker
-- I wonder if there are better options than any.
—
Reply to this email directly or view it on GitHub #1256 (comment)
.
Michel Weststrate (@mweststrate) 'cause that would make a type be either MyClass or MyOtherClass, instead of the actual union of the members: {a: string, b: number} & {d: string, b:string[]} => {a:string, b: number|string[], d:string}.
For now, for Object.assign, I am using an overloaded definition in the lines of:
function assign<A>(a: {}, b: A): A;
function assign<A>(a: A, b: A): A;
function assign<A, B>(a: A, b: B): any; // vs A & B
This works, and is kindof better than the any approach proposed by Duan Yao (@duanyao), because it does help the TS type checker in the nontrivial cases of A and B being of the same type and cloning an object (Object.assign({}, {a:2});). Still 👍 for type intersections.
Michel Weststrate (@mweststrate) The problem of {a: string, b: number} & {d: string, b:string[]} => {a:string, b: number|string[], d:string} is that {a:string, b: number|string[], d:string} is assignable to none of its super types.
Michel Weststrate (@mweststrate)https://github.com/mweststrate The problem of {a: string,
b: number} & {d: string, b:string[]} => {a:string, b: number|string[],
d:string} is that {a:string, b: number|string[], d:string} is assignable
to none of its super types.
—
Reply to this email directly or view it on GitHub #1256 (comment)
.
+1
I am looking forward an expressive solution for something like function (assertAPI, assertExtension) { return mix(assertAPI, assertExtension) } and intersection type would fit right in.
In TypeScript, we use union types to support function overloading.
function f(x: number | x: string): void {
...
}
These two functions actually have the same type because TypeScript used union types to encode intersection types of Flow. Intersection types are the dual of union types. When an arrow is distributed over a union, the union changes to an intersection.
(A -> T) & (B -> T) <: (A | B) -> T
I think adding intersection types makes the type system more orthogonal as we often use intersection types to encode union types or union types to encode intersection types. In case of function overloading, I think union types look more natural to most programmers. But typing Object.assign with union types seems not trivial. (Or is it possible?)
Activity
danquirk commentedon Nov 24, 2014
We talked about these during the process of designing unions but didn't prioritize them highly as we didn't see a ton of compelling use cases. If you have some examples that would be helpful. It's certainly doable.
fdecampredon commentedon Nov 25, 2014
For every function that involves mixins :
danquirk commentedon Nov 25, 2014
Mixins are a good example. We talked about them a bit the other day. I believe we need more than intersection types to model them well though, we specifically talked about what the signature for Object.assign would be, it's more like:
unless we manually write out some number of overloads and just never let you mix in more than x things at a time (which is what your overloads there would do). Perhaps that's an acceptable solution though.
fdecampredon commentedon Nov 25, 2014
Why could we not do both ? in my example the final overload use rest
danquirk commentedon Nov 25, 2014
The overloads would hopefully be unnecessary if we had 'rest type parameters' but both could be useful. In any case, mixins are definitely a good example for this, but they're also something we will look at holistically beyond just intersection types given the desired use cases (ex considering what's mentioned in #727 and #311). If there are other examples worth considering specifically for intersection types we should make sure to get those on paper too.
fdecampredon commentedon Nov 25, 2014
Actually I don't see any other case flow use them to declare function overload, not sure it is really helpful, I guess if we search a bit they could be some special edge case but not that I can think of.
stanvass commentedon Nov 26, 2014
I keep finding uses for intersection types in my code (even before I knew flow has them).
A typical example is an injected dependency in a constructor argument that requires an object implementing several interfaces (the combinations are too many to have dedicated interfaces for every combination) for ex.
I'd really love to see intersection types in TypeScript.
basarat commentedon Dec 11, 2014
A stackoverflow request for the same : http://stackoverflow.com/q/27325524/390330
fdecampredon commentedon Dec 16, 2014
Side note, I think it's important to implements intersection type with an algorithm that take in account that order should matter.
I think it's pretty important
stanvass commentedon Dec 16, 2014
François de Campredon (@fdecampredon) Order should matter if one type can override a definition in another.
But another approach could be that types with (incompatible) property collisions can't be intersected (type error).
It's a matter of avoiding accidental errors vs. flexibility. I think the default resolution should be an error for now, with an open possibility in the future to explicitly declare you're ok with the collision (so one should override the other).
fdecampredon commentedon Dec 16, 2014
Stan Vass (@stanvass) yup valid also
danielearwicker commentedon Mar 22, 2015
It's notable that
Object.assign,$.extendetc. cannot be usefully described by TS's type system and yet such functions are extremely widely used in real JS code.TS gives great support to classes. But using classes means following a particular pattern where I have to use
this, which can mean a lot of quite radical surgery on thousands of lines of existing JS code. I tried converting a few large modules that way, class-izing them, but it was damn hard work. To avoid that pain as I've adopted TS, I've used$.extendand extra interfaces and casting-I-mean-type-asserting.So:
This pattern is type-safe against changes to both the
ICarandISteerableinterfaces: thesobject literal will fail to compile if I don't keep it up-to-date with changes toISteerable.But it is not safe against independent changes to
ISteerableCar. The type assertion in front of$.extendis based purely on trust that future maintainers will read the comment onISteerableCarand not add methods or further base interfaces.Classes don't have this problem:
In JS classes are just syntactic sugar: they don't do anything you couldn't do another way. But in TS classes are magic. They conceal a call to an
extendhelper that is strongly typed, which we cannot do ourselves in TS.With intersection types I wouldn't need
ISteerableCarwith a scare-comment. I'd just sayISteerable&ICar. And with a properly typedObject.assign:The great thing about JS is that by providing the tools needed to build objects dynamically, it allows library authors to come up with their own solutions to mixins, multiple-inheritance, aspect-oriented cross-cutting concerns and so on. So I'd love to see TS striving to be the compile-time equivalent of that.
This means that the logical building blocks of type relationships (such as intersection) should be regarded as important in-and-of themselves. They allow the type system to express things that can be done at runtime, and so they support library authors who experiment with ways of building objects.
Yes, classes are the ready-to-wear approach. But give library authors the building blocks so they can try other approaches. This is JS's strength - it's not frozen into one classical OO-style. But at the moment TS is rather class-biased. And lots of JS experts love to hate classes...
NoelAbrahams commentedon Mar 22, 2015
Where's the evidence for that? Perhaps fairer to say "Lots of small (or legacy) library developers"?
For large-scale application development a class-based approach is the only way. In such a framework, object literals represent the data (while classes represent the business logic). It doesn't pay (in terms of memory, performance and maintainability) to dynamically endow object literals with sophisticated logic as proposed in the example above.
(NB: I don't have any objection to implementing this feature: I only point out that there are good reasons for TypeScript to remain biased towards classes.)
9 remaining items
Ciantic commentedon May 1, 2015
I think the order should not matter, it should throw error if one tries to intersect incompatible field types.
If one really wants to intersect incompatible types there could also be a field removal/complement like in elm-lang's records. If there is intersect, why couldn't there be removal and other set operations, like include only fields in both types.
Complement example:
Complement could work as well with other interfaces:
With complement in place, it's now possible to use intersection both ways without errors:
And it would not cause errors.
P.S. when thinking these as set operations, the word "intersection" is misleading because A intersection B in above example would be empty set! They have nothing in common.
stanvass commentedon May 3, 2015
Jari Pennanen (@Ciantic) It's confusing a bit, but it helps to think about intersection of types, not of their members. An intersection of two types is the union of their members, because the resulting intersection then belongs to both types.
In simpler scalar types intersection has more intuitive results, i.e. the intersection of signed and unsigned byte is -128...127 & 0...255 = 0...127. The resulting values belong to both types.
Also I agree order should not matter, identical properties should merge, incompatible ones should error out. That's the only way to ensure the resulting type is truly an intersection belonging to both types.
duanyao commentedon Jun 5, 2015
+1 for interception types.
But I'm confused with the semantic of interception of primitive types, e.g. what should
string & numbermean? Flow type says it is meaningless:However if interception of primitive types is not allowed, some use cases such as "interface members conflict" can't be modeled properly.
danielearwicker commentedon Jun 5, 2015
Duan Yao (@duanyao) It can be modelled properly - but only where it makes sense. It's just that some types cannot intersect because they involve a contradiction. They disagree about the type of some member, in a way that cannot be reconciled. If we make such a request, the compiler is maximally helpful if it rejects it.
duanyao commentedon Jun 5, 2015
Daniel Earwicker (@danielearwicker) Yes, I am aware of the contradiction. But sometimes the contradiction only exists in TS side, not JS side. In these cases we usually use
anyto bypass TS type checker -- I wonder if there are better options thanany.mweststrate commentedon Jun 5, 2015
If conflicting types are allowed, just use union types, which are already
part of typescript? (e.g MyClass | MyOtherClass)
On Fri, Jun 5, 2015 at 11:06 AM, Duan Yao notifications@github.com wrote:
HerringtonDarkholme commentedon Jun 12, 2015
+1 again for this. It is needed not only by today's
Object.assignbut also by ES7's object spreadDrRataplan commentedon Jun 15, 2015
Michel Weststrate (@mweststrate) 'cause that would make a type be either MyClass or MyOtherClass, instead of the actual union of the members:
{a: string, b: number} & {d: string, b:string[]} => {a:string, b: number|string[], d:string}.For now, for Object.assign, I am using an overloaded definition in the lines of:
This works, and is kindof better than the any approach proposed by Duan Yao (@duanyao), because it does help the TS type checker in the nontrivial cases of A and B being of the same type and cloning an object (
Object.assign({}, {a:2});). Still 👍 for type intersections.duanyao commentedon Jun 16, 2015
Michel Weststrate (@mweststrate) The problem of
{a: string, b: number} & {d: string, b:string[]} => {a:string, b: number|string[], d:string}is that{a:string, b: number|string[], d:string}is assignable to none of its super types.mweststrate commentedon Jun 16, 2015
Ah indeed, overlooked both items. Thanks :)
On Tue, Jun 16, 2015 at 3:09 AM, Duan Yao notifications@github.com wrote:
jpolo commentedon Jun 16, 2015
+1
I am looking forward an expressive solution for something like
function (assertAPI, assertExtension) { return mix(assertAPI, assertExtension) }and intersection type would fit right in.kseo commentedon Jun 17, 2015
+1 for intersection types.
In Flow, intersection types are used to mimic function overloading:
In TypeScript, we use union types to support function overloading.
These two functions actually have the same type because TypeScript used union types to encode intersection types of Flow. Intersection types are the dual of union types. When an arrow is distributed over a union, the union changes to an intersection.
I think adding intersection types makes the type system more orthogonal as we often use intersection types to encode union types or union types to encode intersection types. In case of function overloading, I think union types look more natural to most programmers. But typing
Object.assignwith union types seems not trivial. (Or is it possible?)HerringtonDarkholme commentedon Jun 17, 2015
Kwang Yul Seo (@kseo) Just a side note, flow's intersection type is problematic. Please refer to facebook/flow#342 and https://github.com/facebook/flow/blob/master/tests/intersection/test.js
For TypeScript, because function is bivariant, there is probably fewer problems with intersection type