Dot versus Colon 2 - #111

Here's a few issues I've found:

• Static methods are called using colon syntax (fix here)
• Using union types and shared members (e.g, declare const test: TypeLiteralA | TypeLiteralB; test.sharedMethod()) uses colon syntax, although this can be prevented using a type guard or cast, so it's not a huge problem.
• Similarly, using intersection types (e.g. declare const aPlus: A & { something(): void }; aPlus.hello() results in colon syntax, although this can only be fixed with a cast - type guards don't help.
  • This happens even if you explicitly declare the type separately (e.g. declare type APlus = A & { something(): void }; declare const aPlus: APlus; aPlus.hello())
  • This is one reason that I wanted to be able to use interfaces, to properly handle extending the behavior. In Improve dot vs colon method invocations #109, methods inherited from a parent class/interface will properly behave with !DotMethod unless overridden (in which case you can use !DotMethod if desired)
• There's likely related issues with other advanced types, although I haven't tested them

Sorry if I seem overly critical, I just like to cover the edge cases 😛

I actually remembered why we use : for static methods: when using this in a static method it usually refers to the class itself. If we look at what happens in lua this is perfectly preserved by using the : syntax and adding a 'self' parameter.

These other ones indeed seem like issues and I will have a look at how to resolve those when I have time.

Hmm, that does make sense for static, although there are again cases where APIs expect to be called using dot syntax, which complicates things.

@apemanzilla @lolleko tried to solve by transpiling lambda properties with . and methods with :. Have a look

Is there anything still holding this back?

Found another minor edge case. If you have an instance of an interface extending from two interfaces defining the same method as an arrow function and regular function, it will use the first parent interface to determine the function type. I can't think of any cases where this really matters, though.

declare interface A2 {
    method: () => void;
}

declare interface B2 {
    method(): void;
}

declare interface Thing extends B2, A2 {} // swapping B2 and A2 here changes transpilation

declare const thing: Thing;

thing.method();

@apemanzilla I will merge this once I added some functional tests and had a quick look if there is any easy way to deal with union types.

Thank you!