6 ms·

Nope. This is a common confusion. The set of properties of objects and the sets of objects themselves have a complementary relationship when it comes to union

Nope. This is a common confusion. The set of properties of objects and the sets of objects themselves have a complementary relationship when it comes to union / intersection and subset / superset. Let's define a "property" as being a predicate that is true for all elements of a set. For example, a collection of red objects has the "red" property. A subset of a set of objects can only have the same or more properties than the set you started with. If you take a bunch of marbles of varying colors, selecting a subset of those marbles can yield a set with a new property (such as them all being red), but they are guaranteed to have the "marble" property. A superset of objects can only have the same or fewer properties than the set you started with. Adding marbles to an existing set of marbles can only make "they are all red" become false (if it was true to begin with). Union and intersection have the same duality; the union of two sets has the intersection of its properties, and the intersection of two sets has the union of its properties. These results come from logic, not TypeScript.

yitr 4y ago
maybe a dumb question, but why does wikipedia say typescript is a superset of javascript? https://en.wikipedia.org/wiki/TypeScript https://en.wikipedia.org/wiki/TypeScript
- thoughtspile 4y ago
  Because all valid JS code is also valid TS code (considering implicit any). Or, put another way, the set of all valid JS programs is a subset of all valid TS programs.
- sirmarksalot 4y ago
  Because Typescript is designed to accept any valid Javascript program, the set of valid statements in a Typescript program is a superset of the set of valid statements in a Javascript program. Typescript contains all the rules of Javascript, and then adds some more, but never in a way that contradicts the requirement that a plain Javascript program should compile, so that also means the language specification itself is a strict superset of Javascript.
  - hbrn 4y ago
    Here are 3 statements that were made in this thread: - typescript is a superset of javascript - superset of objects can only have the same or fewer properties - Typescript contains all the rules of Javascript, and then adds some more Do you see where the confusion is coming from? > that also means the language specification itself is a strict superset of Javascript This is where I disagree. TS as a language has more properties than JS, but less rules. I.e. you can create Javascript language out of Typescript by adding more rules (constraints). But TS as a spec has more rules than JS spec. TS as a language is a superset of JS language. TS as a spec is a rough subset of JS spec.
    - jbirer 4y ago
      You are right, the statements are contradictory. It's strange to see how nobody questions marketing buzzwords from Microsoft.
      - goto11 4y ago
        What "marketing buzzwords" are you referring to?
    - eevilspock 4y ago
      You're making this harder than it actually is by conflating a bunch of things, comparing apples and oranges. Sets defined by type vs sets defined by lists of properties, specs, rules etc. For types, just draw the Venn diagrams: - The set of objects of Type A is entirely within the set of objects of Subtype of A. Subtype of A is the superset. - the set of things that are Dogs (class or real world) is entirely within the set of things that are Animals. - the set of things that are Javascript programs is entirely within the set of things that are Typescript programs.
      - hbrn 4y ago
        > Sets defined by type vs sets defined by lists of properties, specs, rules etc. Recursive explanations are useless: "types are just sets defined by types". That's why we are trying to define them through other means. Also TS has structural type system, which is literally about comparing properties.
antihipocrat 4y ago
In your example with marbles, the superset has the property of every element being comprised of a set of colors, let's say {black, red, blue}. The subset is {red}. Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less?
- lmm 4y ago
  > Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less? What do you mean? A superset always contains at least the same number of elements as a subset, by definition. A superset generally has fewer or at least weaker properties; "colour is one of A, B or C" is a weaker property than "colour is A", and there's no real difference between that and saying the superset doesn't have the property at all (I could say "my subset consists of shiny marbles; my subset has the property that they're shiny and my superset does not have that property", or I could say "my subset has the property that shininess is true, and my superset has the property that shininess is true or false", and there isn't really any difference once you get down to the set-theoretic level - a property is just a boolean-valued function). The only superset that has exactly the same properties as the set itself is the set itself (since "is a member of the subset" is a valid property).
  - antihipocrat 4y ago
    Ok, how about I define a new property that my superset contains a 'rainbow' of colors. The subset has only one of the colors, it doesn't contain the rainbow property. The original post claimed that the superset always has the same or fewer properties. I was questioning whether this was true. You've mentioned that it is generally true, which seems like a better way to describe the concept. -- edit: I understand now, in my example above the subset must contain a property by which it could be identified. The original rainbow property is lost but a new one is gained.
    - lmm 4y ago
LudwigNagasena 4y ago
I think that interfaces in TypeScript unfortunately contribute to that confusion. I can do interface Point2D { x: number y: number } And then I can do interface Point3D extends Point2D { z: number } And that "extends" really throws off many people because in reality the type of Point2D is implicitly { x: number y: number [anything_else in string]: unknown } So Point3D actually narrows the type of Point2D even though the notation suggests that it widens it. Fortunately, the type notation is less misleading because I can do type Point3D = Point2D & { z: number } Without any misleading "extensions". It seems like it all stems from the tight coupling between types and classes in a typical OOP paradigm. When you create a class Animal you create a type Animal that should conform to specific rules, but when you instantiate that class you create an object that conforms to a narrower set of rules. E.g. an object instantiated from class Animal won't be able to woof() even though the type "Animal" easily allows it. This leads to the mental model of "extending" base class with new fields and methods. And even though it indeed extends the class Animal, it narrows the type Animal.
- dragonwriter 4y ago
  > So Point3D actually narrows the type of Point2D even though the notation suggests that it widens it. The notation suggests that it extends the definition with additional restrictions. Which it does. Which, yes, produces a narrower scope. That’s how definitions work.
  - LudwigNagasena 4y ago
    In mathematical logic, for example, saying that A is an elementary substructure of B is equivalent to saying that B is an elementary extension of A. The same with subfields and extension fields. Those concepts are opposite. Usually in OOP you extend a class with additional implementation. Intersection of types means union of their members and vice versa. Getting into a situation where extending X gives you a sub-X seems like an unfortunate case of mixing two mental models that behave in a dual manner.
- goto11 4y ago
  "Extends" does not mean it extends the type to contain more members, it means it extends instances to have more properties, thereby creating a subset or subtype. Perhaps it is confusing that TypeScript uses terms from both set-theory (union, intersection) and OO (extends, implements). But there is no contradiction.
Tainnor 4y ago
This depends on what you mean by "property". Universal properties are preserved "downwards" i.e. in subsets (more properly, substructures). Existential properties are preserved upwards, i.e. in supersets (extensions). For example, the property "there exists an element that equals itself when added to itself" is preserved in a superset. If you have sentences that mix quantifiers (e.g. "for all epsilon, there is a delta ..." or even just "every element has an inverse"), then all bets are off. The branch of mathematics where this is studied (and rigorously proven) is model theory. edit: I guess by "property" (given the context of the discussion) you might just mean "function" or "method", in which case, yes, a function defined on a set is also defined on a subset but not necessarily vice versa, so there are in a certain sense "more" functions defined on the subset.
- deleted 4y ago
  [deleted]

yitr 4y ago

maybe a dumb question, but why does wikipedia say typescript is a superset of javascript? https://en.wikipedia.org/wiki/TypeScript https://en.wikipedia.org/wiki/TypeScript

thoughtspile 4y ago
Because all valid JS code is also valid TS code (considering implicit any). Or, put another way, the set of all valid JS programs is a subset of all valid TS programs.
sirmarksalot 4y ago
Because Typescript is designed to accept any valid Javascript program, the set of valid statements in a Typescript program is a superset of the set of valid statements in a Javascript program. Typescript contains all the rules of Javascript, and then adds some more, but never in a way that contradicts the requirement that a plain Javascript program should compile, so that also means the language specification itself is a strict superset of Javascript.
- hbrn 4y ago
  Here are 3 statements that were made in this thread: - typescript is a superset of javascript - superset of objects can only have the same or fewer properties - Typescript contains all the rules of Javascript, and then adds some more Do you see where the confusion is coming from? > that also means the language specification itself is a strict superset of Javascript This is where I disagree. TS as a language has more properties than JS, but less rules. I.e. you can create Javascript language out of Typescript by adding more rules (constraints). But TS as a spec has more rules than JS spec. TS as a language is a superset of JS language. TS as a spec is a rough subset of JS spec.
  - jbirer 4y ago
    You are right, the statements are contradictory. It's strange to see how nobody questions marketing buzzwords from Microsoft.
    - goto11 4y ago
      What "marketing buzzwords" are you referring to?
  - eevilspock 4y ago
    You're making this harder than it actually is by conflating a bunch of things, comparing apples and oranges. Sets defined by type vs sets defined by lists of properties, specs, rules etc. For types, just draw the Venn diagrams: - The set of objects of Type A is entirely within the set of objects of Subtype of A. Subtype of A is the superset. - the set of things that are Dogs (class or real world) is entirely within the set of things that are Animals. - the set of things that are Javascript programs is entirely within the set of things that are Typescript programs.
    - hbrn 4y ago
      > Sets defined by type vs sets defined by lists of properties, specs, rules etc. Recursive explanations are useless: "types are just sets defined by types". That's why we are trying to define them through other means. Also TS has structural type system, which is literally about comparing properties.

antihipocrat 4y ago

In your example with marbles, the superset has the property of every element being comprised of a set of colors, let's say {black, red, blue}. The subset is {red}. Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less?

lmm 4y ago
> Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less? What do you mean? A superset always contains at least the same number of elements as a subset, by definition. A superset generally has fewer or at least weaker properties; "colour is one of A, B or C" is a weaker property than "colour is A", and there's no real difference between that and saying the superset doesn't have the property at all (I could say "my subset consists of shiny marbles; my subset has the property that they're shiny and my superset does not have that property", or I could say "my subset has the property that shininess is true, and my superset has the property that shininess is true or false", and there isn't really any difference once you get down to the set-theoretic level - a property is just a boolean-valued function). The only superset that has exactly the same properties as the set itself is the set itself (since "is a member of the subset" is a valid property).
- antihipocrat 4y ago
  Ok, how about I define a new property that my superset contains a 'rainbow' of colors. The subset has only one of the colors, it doesn't contain the rainbow property. The original post claimed that the superset always has the same or fewer properties. I was questioning whether this was true. You've mentioned that it is generally true, which seems like a better way to describe the concept. -- edit: I understand now, in my example above the subset must contain a property by which it could be identified. The original rainbow property is lost but a new one is gained.
  - lmm 4y ago

LudwigNagasena 4y ago

I think that interfaces in TypeScript unfortunately contribute to that confusion. I can do interface Point2D { x: number y: number } And then I can do interface Point3D extends Point2D { z: number } And that "extends" really throws off many people because in reality the type of Point2D is implicitly { x: number y: number [anything_else in string]: unknown } So Point3D actually narrows the type of Point2D even though the notation suggests that it widens it. Fortunately, the type notation is less misleading because I can do type Point3D = Point2D & { z: number } Without any misleading "extensions". It seems like it all stems from the tight coupling between types and classes in a typical OOP paradigm. When you create a class Animal you create a type Animal that should conform to specific rules, but when you instantiate that class you create an object that conforms to a narrower set of rules. E.g. an object instantiated from class Animal won't be able to woof() even though the type "Animal" easily allows it. This leads to the mental model of "extending" base class with new fields and methods. And even though it indeed extends the class Animal, it narrows the type Animal.

dragonwriter 4y ago
> So Point3D actually narrows the type of Point2D even though the notation suggests that it widens it. The notation suggests that it extends the definition with additional restrictions. Which it does. Which, yes, produces a narrower scope. That’s how definitions work.
- LudwigNagasena 4y ago
  In mathematical logic, for example, saying that A is an elementary substructure of B is equivalent to saying that B is an elementary extension of A. The same with subfields and extension fields. Those concepts are opposite. Usually in OOP you extend a class with additional implementation. Intersection of types means union of their members and vice versa. Getting into a situation where extending X gives you a sub-X seems like an unfortunate case of mixing two mental models that behave in a dual manner.
goto11 4y ago
"Extends" does not mean it extends the type to contain more members, it means it extends instances to have more properties, thereby creating a subset or subtype. Perhaps it is confusing that TypeScript uses terms from both set-theory (union, intersection) and OO (extends, implements). But there is no contradiction.

Tainnor 4y ago

This depends on what you mean by "property". Universal properties are preserved "downwards" i.e. in subsets (more properly, substructures). Existential properties are preserved upwards, i.e. in supersets (extensions). For example, the property "there exists an element that equals itself when added to itself" is preserved in a superset. If you have sentences that mix quantifiers (e.g. "for all epsilon, there is a delta ..." or even just "every element has an inverse"), then all bets are off. The branch of mathematics where this is studied (and rigorously proven) is model theory. edit: I guess by "property" (given the context of the discussion) you might just mean "function" or "method", in which case, yes, a function defined on a set is also defined on a subset but not necessarily vice versa, so there are in a certain sense "more" functions defined on the subset.

deleted 4y ago
[deleted]