Suggestion: Extension methods

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

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

👍

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

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

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

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?

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

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 () {
};

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!

Kagami Sascha Rosylight (@saschanaz)

I still agree with Kagami Sascha Rosylight (@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.

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

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

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@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

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.

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.

✏️

Seems people aren't reading the thread.

Proposal class static block support (microsoft#43370)

fix: enable pnp for `typingsInstaller` and `watchGuard` (microsoft#9)

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

call chaining and fluent usage of extension functions. You can write foo.toBar().toBaz() instead of barToBaz(fooToBar(foo)).
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.

Red Daly (@reddaly)

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

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.

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.

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.

Hi,

I'd really appreciate some guidance.
I was playing around with ast transformers to see if I could have a custom extension method implementation (here: codibre/extension-methods#3).
I achieve making something like that work:

The extension declaration:

import { ExtensionMethod } from 'extension-method';

export class ExtensionTest {
    @ExtensionMethod
    static myTest(str: string) {
        return 123;
    }
}

declare global {
  interface String {
    myTest(): number;
  }
}

Where it is used:

import './extension';

console.log("abc".myTest());

In the test I'm running, it compiles to something like this:

"use strict";
var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
const extension_1 = __importDefault(require("./extension"));
console.log(extension_1.ExtensionTest.myTest("abc"));

Which nails the idea, although there are many scenarios I need to explore.
The issue with this solution, though, is that the extension declared to String here is visible regardless of whether I've imported the extension file. Can I write the "type augmentation" somehow so the extension method will only be visible when I import the file where it is declared?

I see that the extension will only work if I import the extension file, which is ideal for the concept. However, if I could somehow have some "scoped argumentation" for existing types, I'd be able to reflect this behavior also in typescript, but I'm unaware of such a feature.

[wasm] checker: cover legacy null/undefined

Navigation Menu

Repository navigation

Suggestion: Extension methods #9

Add to .prototype

Rewrite call sites

151 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Suggestion: Extension methods #9

Description

Activity

knazeri commented on Jul 29, 2014

basarat commented on Jul 29, 2014

mpawelski commented on Aug 13, 2014

basarat commented on Aug 14, 2014

saschanaz commented on Aug 14, 2014

knazeri commented on Aug 14, 2014

zlumer commented on Aug 15, 2014

saschanaz commented on Aug 15, 2014

knazeri commented on Aug 15, 2014

basarat commented on Aug 15, 2014

knazeri commented on Aug 15, 2014

RyanCavanaugh commented on Aug 15, 2014

Add to .prototype

Rewrite call sites

knazeri commented on Aug 15, 2014

151 remaining items

mikeaustin commented on Apr 19, 2017

atrauzzi commented on May 10, 2017

RyanCavanaugh commented on May 10, 2017

reddaly commented on Jul 15, 2024

RyanCavanaugh commented on Jul 15, 2024

gonzojive commented on Jul 26, 2024

RyanCavanaugh commented on Jul 26, 2024

gonzojive commented on Jul 27, 2024

Farenheith commented on Jan 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions