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

TypeScript should have shorthand get syntax like C# 6.0 #10911

Closed
MrMatthewLayton opened this issue Sep 14, 2016 · 5 comments
Closed

TypeScript should have shorthand get syntax like C# 6.0 #10911

MrMatthewLayton opened this issue Sep 14, 2016 · 5 comments
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript

Comments

@MrMatthewLayton
Copy link

Proposal

TypeScipt should have shorthand syntax for get properties. Please note that this is related to another of my proposals for TypeScript; notably, the ability to output value properties as well as accessor properties.

Rationale

I want to write fewer lines of code and express intent more clearly

What I have to write currently

public get mySuperObjectProperty(): SomeType {
    return this.mySuperObjectPropertiesBackingVariable;
}

What I would like to write

public get mySuperObjectProperty(): SomeType => this.mySuperObjectPropertiesBackingVariable;

On a serious note, TypeScript's property implementation is hideous, and could be much improved to bring it inline with property implementation as of ES5...again, check out my proposal for value properties.

@kitsonk
Copy link
Contributor

kitsonk commented Sep 14, 2016

I suspect this will fall under TypeScript design goal:

  1. Avoid adding expression-level syntax.

And be considered the domain of ECMAScript/JavaScript and that if TC39 agreed to that sort of shorthand, then TypeScript would gladly implement...

This was discussed on ESDiscuss here and there were several reasons why it was not considered a good idea. In particular, the arrow functions in ECMAScript bind to the lexical this, where actually you want a different binding, which means that some arrow functions would bind to a different this and some would not. Very confusing.

@kitsonk
Copy link
Contributor

kitsonk commented Sep 14, 2016

Oh, and non-goal:

  1. Exactly mimic the design of existing languages. Instead, use the behavior of JavaScript and the intentions of program authors as a guide for what makes the most sense in the language.

@aluanhaddad
Copy link
Contributor

@kitsonk I think this could be accomplished by modifying the automatic field creation from constructor arguments annotated with the private, public, and readonly keywords, possibly by adding agetand orset` modifier. Also, I don't think this is about mimicking existing languages as much as it is about borrowing a useful shorthand that a number of languages have adopted.

That said, personally I think that decorators would be a better way to accomplish this. The problem being that they do not affect the type of decorated class. If they did affect the type, class or constructor parameter decorators could accomplish this goal.

I am thinking something like

class Car {
    constructor(@get public make, @get public model, @get @set public miles) { }
}

@kitsonk
Copy link
Contributor

kitsonk commented Sep 14, 2016

Also, I don't think this is about mimicking existing languages as much as it is about borrowing a useful shorthand that a number of languages have adopted.

One persons adopting useful expression level syntax is another person's mimicking existing languages.

The biggest challenge with decorators is they don't mutate types. We may see something that would work in 2.1 if the core team gets the time to address ambient decorators.

@aluanhaddad
Copy link
Contributor

aluanhaddad commented Sep 17, 2016

@kitsonk I agree, and I did indeed mention that my decorator based example would only work if decorators mutated types.

Regarding expression level syntax, my reasoning here was that since TypeScript already allows placing public, private, and readonly before arguments it would not be introducing expression level syntax in a place where TypeScript has not already done so.

@mhegazy mhegazy added Suggestion An idea for TypeScript Out of Scope This idea sits outside of the TypeScript language design constraints labels Dec 14, 2016
@mhegazy mhegazy closed this as completed Apr 24, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants