Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes for 1/29/2016 #6735

Closed
DanielRosenwasser opened this issue Jan 29, 2016 · 3 comments
Closed

Design Meeting Notes for 1/29/2016 #6735

DanielRosenwasser opened this issue Jan 29, 2016 · 3 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Different modifiers for get/set accessors (#2845)

  • People want private/protected set accessors with public get accessors.
    • Or combinations thereof.
  • Why can't people use private backing fields with a readonly accessor?
    • Because that's annoying.
  • We'd need to add modifiers.
  • "Modifier salad"
  • Doesn't really give you the encapsulation that you wanted.
    • "I meant public, but only to certain assemblies.
      • Now you need friend assemblies.
      • Descends into madness.
  • Conclusion: let's see how people use readonly.

Overloads and Union Types (#1805)

declare function alpha(x: number): void;
declare function alpha(x: string): void;

declare function beta(x: number | string): void;

interface SomeInterfaceA {
    foo(x: number): void;
    foo(x: string): void;
}


interface SomeInterfaceB {
    foo(x: number | string ): void;
    foo(x: string): void;
}

class AlphaImpl implements SomeInterfaceA {
    foo(x: number | string): void {
       alpha(x); // error because `string | number` is not compatible
                 // with the first param of either overload

       beta(x);  // okie dokey 
    }
}
  • Do we "tell" people not to use overloads instead of unions?
    • How?
    • We currently don't have any guidance, so we should do that.
    • But it's not like people always look up guidance when they start working on a .d.ts file.
    • Just tell people only use overloads when necessary.
  • People get the intuition that we should "do the right thing".
    • But if there's more than one parameter, this "only sometimes works".
    • "People generally don't expect the case of more than one parameter to work."
      • So we special case that?
      • Sounds terrible.
  • This is similar to the "specialized string" case.
  • Should we go through DefinitelyTyped?
  • It might be possible to write a linting rule for this.
  • Conclusion: nada, give guidance.

Abstract methods with callbacks (#5591)

  • Want to be able to say "Whoever implements/extends me must declare a property named blah."
  • Proposal is
    • to just allow abstract on properties.
    • to ensure class extending an abstract class must implement all abstract properties.
  • What is the distinction between a method and a property here?
  • How does readonly and abstract mix?
  • public static abstract readonly
    • Aha, static is not valid with abstract.
      • Our users will be so disappointed they won't be able to write that.

Using string indexers with string-intersected types (#4372, #5599)

  • Motivation is:

    type Path = string & { __somePathThing: void };
  • People shouldn't do that.

    • Because it's just a hack.
    • But it's useful.
    • So let's make it not a hack.
  • Really you want a "fresh type".

    • How do you express that?

    • Like this?

      type InternedString = new string;

      or maybe

      type InternedString = tagged string;
    • InternedString is assignable to string.

    • string would not be assignable to InternedString.

    • How do types compose?

      type InternedString = new string;
      type Path = new string;
    • How do I create an interned path?

      • Intersection types?
    • What is the quick info for this?

      • tagged string would be horrible.
    • What's the point of tagged string anywhere other than a type alias?

    • Why don't we just create a new declaration instead of piggybacking on type aliases? (e.g. newtype)

      • These declarations are nominal anyway.
      • That might just be what we want.
      • But why just these declarations?
    • Do we just want a construct that always generates a globally unique or "fresh" type?

    • Something like this:

      type Path = string & ????;
      
      class Foo {
          ????
      }

      where ???? is that globally unique or "fresh" type.

      • Maybe ???? is new or something.

      • How would a fresh type propagate with aliases?

        type Tag = new; // or 'unique' or whatever
        var x: Tag;
        var y: Tag;
        • Do A and B have identical types?
      • Would we only allow this on primitives and object types?

        • Why not unions/intersections?
          • No clear reason why, but how do you work with this?
    • But people don't want to use a tag for every class. They just want nominal.

      unique interface PathTag {
      }
      
      unique class Foo {
      
      }
      unique type Path = string;
      • Uh-oh, what about type literals?

        var x: unique { }; // wat
      • Restrict this to declarations and this becomes less insane, easier to implement.

  • _So back to the original question!_

  • Would all those zany new types intersected with string still be allowable in an index signature?

    • Probably. 👍
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jan 29, 2016
@mhegazy
Copy link
Contributor

mhegazy commented Jan 29, 2016

Revisit default module option

Conclusion: node should be the default.

@zpdDG4gta8XKpMCd
Copy link

might be related #4895

@DanielRosenwasser
Copy link
Member Author

Keywords: to make it easier to find this: tagged, nominal, branded, opaque, unique, fresh.

Also linking to #202.

@microsoft microsoft locked and limited conversation to collaborators Jul 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

3 participants