Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extension methods for interfaces #24889

Closed
oliverjanik opened this issue Jun 12, 2018 · 8 comments
Closed

Extension methods for interfaces #24889

oliverjanik opened this issue Jun 12, 2018 · 8 comments
Labels
Duplicate An existing issue was already created

Comments

@oliverjanik
Copy link

Apologies I this is a dup.

The situation comes up often. I define an interfaces for my API JSON responses and I wish they were classes so I could define instance methods on them. Say for mutation, or just helpful convenience methods.

Sure I can use standalone functions that take the interface as the first parameter but discover-ability sucks.

Something like this:

interface Rect {
    x: number;
    y: number;
    width: number;
    height: number;
}

function area(rect: this Rect): number {
    return rect.widht * rect.height;
}
@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jun 12, 2018

Unfortunately if the proposal is that that syntax enables users to write

declare let x: Rect;
x.area()

then this would be type-directed syntax, and also falls out of our design goals in that it extends ECMAScript past the type space. You might want to keep an eye on the pipeline operator (|>, tracked at #17718) or the less-likely bind operator (::, tracked at #3508).

@oliverjanik
Copy link
Author

Interesting. Thanks for pointers.

Different operator, however, does not fix discoverability problem as everyone is just used to typing dot and get suggestions.

@mhegazy
Copy link
Contributor

mhegazy commented Jun 12, 2018

Duplicate of #9

@mhegazy mhegazy marked this as a duplicate of #9 Jun 12, 2018
@mhegazy mhegazy added the Duplicate An existing issue was already created label Jun 12, 2018
@oliverjanik
Copy link
Author

oliverjanik commented Jun 13, 2018

@mhegazy Wasn't #9 closed due to inactivity?

Edit: Sorry, I thought you closed this issue.

@kitsonk
Copy link
Contributor

kitsonk commented Jun 13, 2018

@oliverjanik no, read the thread, it was closed because it was deemed out of scope, because there are some major problems with implementation that make it not practical to be considered. Because people were not reading the thread and understanding that it is not implementable, the whole thread had to be locked.

This is asking exactly for a feature which is out of scope, so it is a duplicate.

@oliverjanik
Copy link
Author

I understand it's impractical and type driven syntax.

On the other hand it's impossible in plain JS because JS doesn't know about interfaces. They're compiled away.

So while you can monkey-patch classes in JS, interfaces will never be possible.

Not sure if there's any way forward on this.

@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@grennis
Copy link

grennis commented Sep 19, 2019

@oliverjanik I'm facing the same limitation (no instance methods on objects deserealized from JSON). What's the best way you found to work around it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

6 participants