Design Meeting Notes for 11/13/2015

[DanielRosenwasser]

Acquiring Typings as Packages (#5537, typings/discussions#3)

• This is fairly important given that getting typings is a big pain point for customers.
• Blake has an implementation of a typings registry.
• What is the workflow between Typings' registry and npm?
  • Considering distributing typings as npm packages.
  • SystemJS and AMD introduce certain complications.
• How does this system figure out the conflicting versioning problem?
  • npm does much of the hard work here with deduplication.
  • Package scopes would help alleviate pain points.
• Lots of open questions - things are in flux and experimental right now.
• Hopefully we'll have more information with a proposal by next week.

Internal Modifier (#5228)

• Public within .ts files in a single program.
• If used in a .d.ts program, treated as private/protected
• internal members get type any when generating a .d.ts file.
• Makes things work kind of like in C#.
  • Assuming .d.ts is an external library.
• Consumers who subclass cannot access the internal member
  • Subclasses still consistently compatible with their base type.
• When is this useful?
  • Kind of like every entity within your program is a "friend" of internal members.
  • Seems to really boil down to .d.ts generation and how users expose portions of their API.
• What about protected internal?
  • No. We're not doing that.
• What about internal for modules/namespaces?
  • Ron wants to take it one step at a time.
  • Things get muddy, so we'd need to experiment.
• Does this solve real-world problems, both now and if eventually extended to modules/namespaces/interfaces?
  • All uses of /* @internal */ in Angular's codebase is on class members.
  • Not entirely an issue for modules?
    • One could create a file that re-exports the public portions of your API.
    • Some issues, but could be done.
    • What does it actually mean for modules?
      • Example: internal caches
      • Instances where one wants to extend an API rather than compose.
    • Looks like there is eventual value for modules.
  • An issue for namespaces.
    • We need it within the compiler.
    • Modules seem to be the way forward anyway, so we need to take that into account.
  • Cancellable promise design lends well to motivation.
    • Internal state is... well, internal.
    • But implementation needs to modify state.
• What about interfaces?
  • This can be taken care of by writing two interfaces.
    • Structural typing takes care of the rest.
  • But that stinks for the author of the library.
    • You either write a bunch of wrapper functions or you end up writing a ton of type assertions.
  • We could do something with interfaces.
    • internal members within an interface would need to be treated nominally.
    • But it's sort of weird to have interfaces with modifiers now whose declarations are treated nominally.
    • But it's already sort of weird given that an ambient class and an interface can merge today and effectively do the same thing.
  • But could you ever implement an interface with internal members from the outside?
    • Is that a good thing?
    • Seems plausibly useful - lets users express certain patterns difficult with structural types.
    • You can create something of some type internally, but never manufacture it from the outside.
• Introduces notion of a "compilation [unit]".
  • What about when a user wants to fake the original compilation unit as part of a different compilation unit.
    • Rename the .d.ts to .ts?
• How are we feeling about this so far?
  • We know some partner teams would be very happy with it.
  • Users familiar with OO languages will be happy to have it.
  • Doesn't solve problems within our compiler - we'll have to continue using --stripInternal.
• What about a flag that specifies whether or not a user wants to respect internal?
  • Kind of weird - not granular enough.
    • You could accidentally use another library's internal members.
  • Would consumers who use the flag affect their consumers?
    • No.
      • "Respect internal" consumers don't infect their consumers with the flag.
• There is a weird dichotomy between internal in a .ts file and a .d.ts file.
  • The modifier means something completely different in each file type.
• What about users decorators?
  • Modifiers are (kinda-sorta) like "burnt-in decorators with fixed meaning".
    • Let users define their own internal semantics.
  • We'd need ambient decorators.
  • Also doesn't work on everything.
    • Function declarations can't be decorated.
    • Not necessarily a problem with ambient decorators.
• Symbols might be another solution to this, but our symbol support in the type system is lacking for these scenarios.
• What is customer demand?
  • Decent demand, but not fully clear.
  • Definite use cases.
  • We run into it ourselves.
  • Every time customers ask about it, we point them to the "undocumented" --stripInternal flag.
• We would prefer a generalized semantics.
  • --stripInternal nor internal really cover all the use-cases.
• There's some hesitation to add another modifier.
  • Ambient decorators would work but...
    • Decorators are another cognitive load, just pushed onto the users.
  • What about when users ask about protected internal?
• We're going to need to sit on it and ponder.