Extension methods already exists

[staeke]

Search Terms

extension methods

Suggestion, part 1

With the risk of you stopping to read here, this is related to extension methods: #9. I actually wrote a post on this #35280, but I guess notifications are turned off when the issue is closed, so with the risk of being perceived as slightly spammy I post again.

@RyanCavanaugh and @hax: Extension methods already exists! Eh...what? Well, I thought I'd write a language service plugin (see #35280), only to realize, they actually work well enough for me already, with symbols and classic Javascript prototype extensions. The idea is to just extend e.g. Date with a isLeapYear (or Object with IFooExtensionMethod) and add the right typings. See https://github.com/staeke/ts-extension-methods. This requires typescript@next since some bug for auto-complete suggestions was recently fixed. Please tell me if there's something I've missed!

So suggestion 1 - promote this style. No actual language change.

Suggestion, part 2

In terms of syntax, this works and is terse on the consumer side, but maybe a little verbose on the provider side (less of a problem though). If you wanted to fix that here are some thoughts:

// First simplify extending types in general, by skipping the declare module syntax.
// Rather reuse "extends" (symbol after is non-ambiguous, auto-import works.)
// Also you can choose whether it's just typings (abstract, no implementation) 
// or an expected prototype override (implementation) which will add to prototype
extends Date {
  someMethod(); // Just typing
  isLeapYear(this: Date) { .. } // Will extend Date.prototype
}

// Now we want symbols, and a way to export those so we allow that inline
extends Date {
  [export symbol isLeapYear]: function(this: Date) {...}
}

// For interfaces
extends Object {
  [export symbol bar]: function(this: IFoo) { ... }
}

This would be equivalent to

export const isLeapYear = Symbol()

function isLeapYearImpl(this: Date) { .. }

declare global {
    export interface Date {
        [isLeapYear]: typeof isLeapYearImpl;
    }
}

Date.prototype[isLeapYear] = isLeapYearImpl;

Examples

Checklist

Suggestion 1 (nothing) obviously meet all criterias. Suggestion 2:

• [ x ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [ x ] This wouldn't change the runtime behavior of existing JavaScript code
• [ x ] This could be implemented without emitting different JS based on the types of the expressions
• [ x ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [ x ] This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

This is type sugar for letting someone write someDateValue[isLeapYear]() ?

[hax]

As I understand, extensions should be static, which means it should only available when extensions is imported and should not affect the original class/object. Symbol-based solution can't achieve that. Actually this idea look likes a mix of partial class and first-class protocol proposal.

IMO, the "real" extensions proposal (for JS/TS) and first-class protocols could be designed to complement each other.

[electricessence]

Keeping any eye on this... Been reading the other discussions too.
I've curated a linq style lib for years and love seeing these ideas.
Not holding my breath tho.