Suggestion: Extension methods

[RyanCavanaugh]

Allow a declarative way of adding members to an existing type's prototype

Example:

class Shape {
 // ...
}

/* ...elsewhere...*/
extension class Shape { // Syntax??
    getArea() { return /* ... */; }
}

var x = new Shape();
console.log(x.getArea()); // OK

[knazeri]

Highly suggested 👍
This would add methods to existing types without creating a new derived type or modifying the original type and it would definitely make sense in linq to typescript query operators

The original issue at codeplex had pretty much lots of votes:
https://typescript.codeplex.com/workitem/100

[basarat]

👍

[mpawelski]

👍

[basarat]

Perhaps this can be used in an ambient context as well :

declare module foo{
    class A{}
    extension class A{} 
}

[saschanaz]

extending A { } for short? I think we don't need class there.

[knazeri]

A couple of questions:
What would be the compiled js like? And how would be the runtime interoperability with the existing class?
Extension methods in C# are static methods with syntactic sugar for instance method call syntax with the first parameter specifying the type the method operates on. Which brings some benefits beside the instance call syntax:

• Extension methods can be called directly as static method call
• Extension classes are not newable
• There could be different extension methods on the same type in the same namespace as long as each class containing extension methods has its own identifier

Having considered extension class syntax, is extension class actually a class or a module at runtime? How do you translate this in a body of an extension method at runtime? (Function.apply, Function.call maybe?) And how would extension methods be like on an interface which I believe is the most commonly use case for extension methods?

[zlumer]

While the naive implementation of extension methods is probably like this:

extension class Shape { // Syntax??
    getArea() { return /* ... */; }
}
console.log(x.getArea()); // OK

Compiling to:

// js
var _Shape = {
    getArea:function() { return /* ... */; }
}
console.log(_Shape.getArea.call(x));

I think due to first-class functions in JS there is a problem with this approach:

extension class Shape { // Syntax??
    getArea() { return /* ... */; }
}
var x = new Shape();
var y = new Shape();
console.log(x.getArea); // Function or undefined?
x.getArea.foo = "bar";
console.log(y.getArea.foo); // "bar" or undefined?

If extension methods are to be implemented, there would probably have to be restirictions on accessing/changing their properties.

Considering "class" syntax

extension class Shape { // Syntax??
    getArea() { return /* ... */; }
}

In my opinion, one of the common uses of extension methods is to make them work on interfaces, not just classes, so you could do something along the lines of

interface IPoint {
    x:number;
    y:number;
}
class Point implements IPoint {
    constructor(public x,public y) {
        // ...
    }
}
var p1:Point = new Point(0, 50);
var p2:IPoint = { x:32, y:32 };

console.log(p1.getLength()); // extension method
console.log(p2.getLength()); // same extension method

If possible, I think C#-like extension methods would work best:

extension function getLength(this p:IPoint):number {
    return Math.sqrt(p.x*p.x + p.y*p.y);
}
// another extension method with the same name but for different class
extension function getLength(this s:string):number {
    return s.length;
}

console.log(getLength); // compiler error
console.log(p1.getLength); // Function or undefined or compiler error?
console.log(p1.getLength.foo); // compiler error
p1.getLength.foo = "bar"; // compiler error

Compiling to:

// js
function _IPoint$getLength() {
    return Math.sqrt(this.x*this.x + this.y*this.y);
}
function _string$getLength() {
    return this.length;
}
console.log(_IPoint$getLength.call(p1)); // OK
console.log(_IPoint$getLength.call(p2)); // OK

[saschanaz]

Hmm, I thought that this proposal was just to extend prototypes.

class A {
    foo() {

    }
}
extending A {
    bar() {

    }
}

Compiling to:

var A = (function () {
    function A() {
    }
    A.prototype.foo = function () {
    };
    return A;
})();
A.prototype.bar = function () {
};

[knazeri]

I don't think extension methods should be implemented by adding a function to the prototype! For one thing extending the prototype of built in types, is considered dangerous, 3rd party libraries may also add a method with the same name to the prototype, causing the behavior to depend on which JS file was loaded last, or worse you might overwrite the existing built-in methods! And for another, there's no way to have different method overloads for the extension methods defined in different modules!
More importantly, prototype extending works only for concrete classes, in a sense, no interface or declared class extension methods!

[basarat]

I still agree with @saschanaz . There are issues surely but for :

3rd party libraries may also add a method with the same name to the prototype, causing the behavior to depend on which JS file was loaded last, or worse you might overwrite the existing built-in methods

this would be caught by name collision in the lib's .d.ts file and your custom.d.ts file.

More importantly, prototype extending works only for concrete classes, in a sense, no interface or declared class extension methods

I don't expect it there to be any codegen for ambient declarations. PS: If you ambiently say something is a class TypeScript already assumes it has a prototype. e.g.

declare class Foo{}
console.log(Foo.prototype); // Compiles fine

So adding to the ambient prototype is consistent with what already exists.

Perhaps examples of your concerns (if still there) would help.

[knazeri]

this would be caught by name collision in the lib's .d.ts file and your custom.d.ts file.

This is only true if there is .d.ts metadata for every 3rd party library (which is not) and only when .ts files are being compiled together (ie. in the same project). Besides there are lots of .js libraries as part of server-side environment which are being injected into dynamic pages at runtime (take asp.net server controls for example)

If you ambiently say something is a class TypeScript already assumes it has a prototype

Ambient class declaration does not have implementation, which is not the case for extension methods, unless extension methods for ambient class declarations are being erased in the compiled .js (which I believe is counterproductive to it's purpose), the program might break at runtime!

And how about interfaces? To extend an interface new methods has to be added to the interface, but changing the interface by adding new methods would break compatibility with existing consumers! Take IEnumerable<T> in C# for example, I cannot imagine how many classes are already implementing this interface! Without having extension methods on interfaces, there could be no LINQ as we know it!

I believe the real advantage of extension methods is being loosely coupled with the existing type, e.g.

Array.prototype.join = function (inner, outerKeySelector, innerKeySelector, resultSelector) {
};

The above example is supposed to add linq-like join operator for arrays, however having altered the prototype, we have lost the built-in join method. Having extension methods separated in a concrete different method actually benefits better method overloading.

There's also a big benefit with generic extension methods which is reducing the need for a common base class.
The following is an example of using generic extension method in C#:

public static bool In<T>(this T obj, params T[] source)
{
    return new HashSet<T>(source).Contains(obj);
}

Which you can simply use:

var o = 1;
o.In(1, 2, 3, 4, 5); /// true

[RyanCavanaugh]

Great discussion so far.

There's a key decision point here on this feature, which is how the emitted code would work. I see two options based on what's been discussed so far

Example code I'll use

class Square { /* ... */ }
extension function getArea(this: Square) { // First param must be 'this'
    return this.width * this.height;
}
var x = new Square(10, 10), y: any = x;
console.log(x.getArea());
console.log(y.getArea());

Add to .prototype

/* Regular emit for 'Square' here */
Square.prototype.getArea = function() {
    return this.width * this.height;
}
var x = new Square(10, 10), y = x;
console.log(x.getArea());
console.log(y.getArea()); // Succeeds

Pros

• Works even if type information is missing (y)
• Accurately models many existing libraries' behavior

Cons

• Doesn't work for interfaces, which is probably a primary use case
• Adding to prototype is often a bad idea, especially for built-in objects

Rewrite call sites

/* Regular emit for 'Square' here */
__Square_getArea = function() {
    return this.width * this.height;
}
var x = new Square(10, 10), y = x;
console.log(__Square_getArea.call(x));
console.log(y.getArea()); // Fails

Pros

• Works on interfaces as well as classes
• Don't mess around with prototype, so it's safe for built-in types

Cons

• Unclear what it means to use this method in a non-call position
• Fails unexpectedly when strong type information is absent
• Doesn't model existing JS library behavior; we'd still then need an alternate syntax for those

[knazeri]

@RyanCavanaugh I would alter the example code, to use the type parameter for the extension method instead of dynamic binding of this :

class Square { /* ... */ }
extension function getArea(this square: Square) { // First param must be 'this'
    return square.width * square.height;
}
var x = new Square(10, 10);
console.log(x.getArea());

Which would translate to this:

function getArea(square) {
    return square.width * square.height;
}
var x = new Square(10, 10);
console.log(getArea(x));

So that the function behave like a static helper method and it's valid to call it non-instance way. However still fails when strong type information is not present. You can call the extension function explicitly:

var x = new Square(10, 10), y:any = x;
console.log(x.getArea()); // Succeeds
console.log(getArea(y));  // Succeeds

[ivogabe]

I like the suggestion of @KamyarNazeri, this can be used on an enum (or an union in the feature) too. This code is also faster than a prototype call or a .call().

Would the extension keyword be necessary? Since you already add this to the first argument.

[knazeri]

@ivogabe +1 for mentioning enum, I would like to also mention that using static functions, you can call methods on objects that are null, e.g. isNullOrEmpty for string type. small things yes, but darn useful

[saschanaz]

How about this?

class Square { /* ... */ }
function getArea() joins Square {
    return this.width * this.height;
}
var x = new Square(10, 10);
console.log(x.getArea());

Translates to:

/* Regular emit for 'Square' here */
__Square_getArea = function(_this) {
    return _this.width * _this.height;
}
var x = new Square(10, 10);
console.log(__Square_getArea(x));

PS: Or without renaming, as @KamyarNazeri did. I like the non-instance way.

function getArea(_this) {
    return _this.width * _this.height;
}
var x = new Square(10, 10);
console.log(getArea(x));

[RyanCavanaugh]

I want to emphasize the danger of the "rewrite call sites" approach:

class Square { /*... */ }
/* Extension method getArea, syntax irrelevant */
function process(callback: (n: Square) => void) {
    /* invoke callback on a variety of Squares */
}

process((n) => {
    n.getArea(); // Succeeds
});
process(((n) => {
    n.getArea(); // No compile error, fails at runtime
}));

var x = new Square(), y: any;
var arr1 = [x];
arr1[0].getArea(); // Succeeds
var arr2 = [x, y];
arr2[0].getArea(); // No compile error, fails at runtime

There are very strong reasons TypeScript avoids rewriting code based on type information (see https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals). No one wants to get in a situation where adding a non-observed element to an array or adding extra parentheses around a function could causes program to start to fail at runtime.

[knazeri]

@RyanCavanaugh Seriously I don't understand why by adding extra parenthesis around a lambda function, the runtime infers variable n as any?
It's like to evaluate variable b's type argument in the following code as any (which is not)

var a = function (n: number): void { }
var b = (a);  // here b accepts number!

As for the latter example, I believe no-one expects an extension method to work when boxing variable to another type (here any due to the type mismatch in the array). At least this is how C# / VB work, with boxing to another type, there's no extension method! Only they don't compile in such situations.

[danquirk]

We explicitly decided parenthesizing an expression should be the way to opt out of contextual typing or else you were always at the mercy of the inference algorithm even if it was wrong/incomplete.

[saschanaz]

Maybe we can choose separate syntax to call those functions.

class Square {
  foo() {
  }
}
function getArea() joins Square {
  return this.width * this.height;
}
var x = new Square(10, 10);
var y: any = x;
console.log(x calls getArea()); // Succeeds
console.log(y calls getArea()); // Succeeds both in compiling and in runtime.
console.log(x.getArea()); // Fails, this is only for functions in prototype
console.log(x calls foo()); // Fails, this is only for extension functions

PS: Fixed to allow y calls getArea().

[knazeri]

This turned to be more complicated that it looked like! Having rewrite call sites comes handy when coding, however I agree that the code might break at runtime! I've seen lots of javascript developers debugging their code in the browser developing tools which also fails using rewrite call sites.
But the ability to extend interfaces is so good that you can't simply ignore it, so probably we are addressing two different problems here:

• Extending a class (by using extension methods)
• Extending interfaces (including built-in types since built-in types are represented as interfaces in the typescript runtime)

Maybe we could consider Java 8 default methods (or as they are often called defender methods) to extend an existing interface. Of course default methods in an interface could translate back to prototype in the emitted js code:

interface ISquare {
    width: number;
    height: number;
    default getArea(): number {
        return this.width * this.height;
    }
}

class Square implements ISquare {
    constructor(public width: number, public height: number) {
    }
    // no need to implement getArea here
}

var x = new Square(10, 10), y: any = x;
console.log(x.getArea());  // Succeeds
console.log(y.getArea());  // Succeeds

which would compile to:

var Square = (function () {
    function Square(width, height) {
        this.width = width;
        this.height = height;
    }
    Square.prototype.getArea = function () {
        return this.width * this.height;
    };
    return Square;
})();

[basarat]

default methods in an interface could translate back to prototype in the emitted js code

This interface looks more like an abstract class. #6

[knazeri]

This interface looks more like an abstract class.

Only a class might already inherit another base class, I think the real benefit with interface extension comes with multiple inheritance simulation.

[ivogabe]

Maybe we could consider Java 8 default methods

The difference is that interfaces in TypeScript can be used without classes. How would the following code compile?

interface ISquare {
    width: number;
    height: number;
    default getArea(): number {
        return this.width * this.height;
    }
}
var square: ISquare = {
    width: 100,
    height: 50
};
console.log(square.getArea);

Maybe we can choose separate syntax to call those functions.

Maybe call the function like this: (since this syntax already exists)

getArea(square);
// instead of
square calls getArea();

[saschanaz]

Maybe call the function like this: (since this syntax already exists)

Chaining would become uncomfortable in that case. Example:

var num = new Number(0);
function plus(input: number) joins Number {
  return this.valueOf() + input;
}
num.plus(3).plus(3).plus(3);
num calls plus(3) calls plus(3) calls plus(3); // Well... not very good to see. Hmm

versus

plus(plus(plus(num, 3), 3), 3);

...while the rewritten JavaScript will be anyway plus(plus(plus ... form.

Edited:

num->plus(3); // Syntax that looks like the C++ one but for extensions?

or

num<-plus(3); // function 'plus' joins to 'num'.

[knazeri]

Yea well, object literals are not the only problem:

interface A {
    default void foo() {
        console.log("A");
    }
}

interface B {
    default void foo() {
        console.log("B");
    }
}

class Bar implements A, B {
    default void foo() {    // required for conflict resolution
        console.log("Bar"); 
    }
}

var o = new Bar();
A o1 = o;
B o2 = o;
o.foo(); // Bar
o1.foo; // probably want A
o2.foo; // probably want B

From the client code perspective, default methods are just ordinary methods, so in case of the simple example with one class that implements an interface with a default method, prototype seems to be fine, however most of the time client code that invokes the default method will have to invoke the method at the call site. same old story. 💤

[zlumer]

For the record, here's an example of runtime exceptions in C#:
http://stackoverflow.com/questions/5311465/extension-method-and-dynamic-object-in-c-sharp
While TypeScript is certainly far more likely to have untyped variables than C# (I myself have about 60% variables untyped in my TS code and only about 10% untyped in C# code), this can be considered a known limitation. Maybe extension methods should only work with a "--noImplicitAny" compiler flag to decrease the possibility of a runtime error.

Personally I'm strongly against any silent prototype modifications - changes to any existing prototype (everything except initial class-defining code generated by TS compiler) should always be explicit, having programmer manually type "class.prototype" to prevent at least some part of the errors.
Having said that, there's absolutely no reason to introduce new syntax for prototype extending: you can always do Square.prototype.getArea = /*...*/ and get all the syntactical benefits of such approach. If "rewriting call sites" is considered inappropriate, I think it's best to not introduce extension methods at all, than confuse programmers with a very dangerous silent prototype-changing feature.

Extension methods are nothing more than syntax sugar for method calls (at least that's how I see it and how they are implemented in C#). While certainly useful, they are not necessary.

[mikeaustin]

@aluanhaddad Ahh yes, Scala implicits. Ok, I'll refer to the other way round as "lexically scoped methods". I've been playing a bit more with seamless extension methods in a language I'm prototyping. I've found this works for calling the object method before any extension methods:

(10).toString ? (10).toString() : _toString.apply(10)

And the other way around, lexically scoped methods with fallback to object methods:

typeof _toString === "undefined" ? (10).toString() : _toString.apply(10)

The language does not do static type-checking, so a TypeScript version would probably need a different approach. The above can be / is slow since it has to do that at each call site. But like I said, I'm just prototyping and getting a sense of how it could work.

[aluanhaddad]

In both C# and Scala an instance method will always win out in terms of overload resolution so I think that's a good approach.

The problem with applying that approach in TypeScript is not static checking but rather that it is impossible to do it without resorting to type directed emit, which is not an option.

[mikeaustin]

I see the type-directed-emit topic comes up with async/awat, but other than that is it not used anywhere else? Sorry, I don't mean to keep this topic alive forever :)

Side note -- taking your extension methods comments to heart, I've come up with this for my language:

(foo.toString || _toString).apply(foo, []); // Syntax emmited for: foo.toString()

Again, it's not going to be fast, but at least it's short.

[aluanhaddad]

@mikeaustin I like it, that's a very clean emit, I'm curious to see how your language progresses.

With respect to type directed in async methods, IIRC it only rears its ugly head when you don't use type inference for return types and don't install a global Promise polyfill, as it only considers the type when provided, defaulting back to the global Promise.

I couldn't care less about the extra methods available on Bluebird Promises and I never specify the return type of async methods.

So I believe the issue is easily dodged, but I may be wrong and it may be affecting me in some other way that I'm not aware of.

[mikeaustin]

Sorry for spamming the TypeScript list, but I made a slight change in my extension methods to support traits/mixins that might be interesting. When extension methods were in local scope, there was no good way (aka not using eval()) to dynamically add methods.

So, I encapsulated them in a _methods lexically scoped object:

var Iterable = new Trait({
  // iterator() can be an extension method or a plain old function
  map: (iterator) => (func) => { var iter = iterator.apply(this); ... }
});

var _methods = Extension.extend(_methods, String, {
  iterator: () => { return new Iterator(this); }
});

// Bind all the trait methods and pass them to extend String
var _methods = Extension.extend(_methods, String, Iterable.bind(_methods.iterator));

_methods.map.apply("abc", [c => c.charCodeAt(0)]); // [97, 98, 99]

I can probably simplify extend() a bit more. The language this is targetting: Impulse-JS.

[atrauzzi]

With the amount of library authoring going on and what seems like increased adoption of TS, now seems like a great time to dust this idea off and see if it's worth dedicating resources to!

Again, biggest thing is for libraries. I already find myself very badly wishing for some kind of idiomatic way to sprinkle some extensions around.

✏️

[RyanCavanaugh]

Seems people aren't reading the thread.

[reddaly]

I would personally be happy if Typescript had extension methods that used a distinct call syntax vs. normal method invocations.

For instance:

function Date#toProto(): Timestamp { ... }

function usage() {
  const proto: Timestamp = new Date()#toProto(); // instead of toDateProto(new Date())
}

This would allow

1. call chaining and fluent usage of extension functions. You can write foo.toBar().toBaz() instead of barToBaz(fooToBar(foo)).
2. easy discovery of extension functions through IDE autocomplete. new Date()# or new Date(). would show toProto() in the autocomplete list; selecting that item could auto import the extension function. Such functions might be more easily discoverable compared to toDateProto().

I suspect it would avoid some of the complications from #9 (comment). Making extension functions callable from JavaScript might require some attention, however.

[RyanCavanaugh]

@reddaly out of scope for TypeScript. See https://github.com/tc39/proposal-bind-operator though

[gonzojive]

What makes the #9 (comment) suggestion out of scope for TypeScript?

Extension methods seem like they should be resolved at compile-time based on typing information that's out of scope for ECMAScript. I'm not sure how ECMAScript could possibly provide the same level of utility through the bind operator.

function Foo::toProto(): FooProto { ... }
function Bar::toProto(): BarProto { ... }

(new Foo())::toProto() // resolves to first method
(new Bar())::toProto() // resolves to second method

---

edit:

Reading into https://github.com/tc39/proposal-bind-operator, it seems the "::" would help a lot. However, in the above example, multiple "toProto" methods probably could not be imported into the same TypeScript file - they would have to be aliased.

import {toProto as toFooProto } from './foo-extensions'
import {toProto as toBarProto } from './foo-extensions'

(new Foo())::toFooProto()
(new Bar())::toBarProto()

This might seem like a small detail, but the namespacing provided by a method receiver is helpful for keeping method names concise.

[RyanCavanaugh]

Extension methods seem like they should be resolved at compile-time based on typing information

That's type-directed emit. See https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#non-goals point 4:

[Do not] Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

[gonzojive]

Thanks. It seems the more active proposal is https://github.com/tc39/proposal-extensions. I asked here about the status of that proposal advancing to stage 2. Presumably TypeScript is not interested in introducing its own bind operator before there is consensus to add the operator to JavaScript.