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

Support ECMAScript 5 (Accessors)? #9

Closed
Bartvds opened this issue Feb 1, 2014 · 2 comments
Closed

Support ECMAScript 5 (Accessors)? #9

Bartvds opened this issue Feb 1, 2014 · 2 comments

Comments

@Bartvds
Copy link
Contributor

Bartvds commented Feb 1, 2014

Would be nice if getters/setters would work:

./src/xm/data/PackageJSON.ts(62,3): error TS1056: Accessors are only available when targeting ECMAScript 5 and higher.
./src/xm/data/PackageJSON.ts(66,3): error TS1056: Accessors are only available when targeting ECMAScript 5 and higher.
@lbovet
Copy link
Owner

lbovet commented Feb 1, 2014

I think that accessors can be declared only in classes and not in interfaces. Typson uses interfaces as source.
I see accessors as a way to implement a property, not as something to be part of the interface. Both should be separated:

interface Foo {
   bar: string;
}

class MyFoo extends Foo {
   get bar(): string {
      return "hello";
   }
}

@Bartvds
Copy link
Contributor Author

Bartvds commented Feb 1, 2014

Yea, you can only declare them classes. But conceptually a type is a type right?

For checking signatures the way the compiler (or json-schema itself) do it doesn't really matter which is which.

I never generate really separate interfaces for my classes, it is a hassle to maintain. And unnecessary in TS; as type is about shape of object, not the named type.

I sometimes even switch my code between interface or class when I describe JSON objects, it is handy top get a default object for that interface. (class maybe without methods, or only static helpers).

So there are two things:

  1. support ES5 is so far as to extract the code for interfaces but not balk over ES5 features in untouched parts of code. Maybe this already works?
  2. actually support he ES5 features themselves. They could be used by the types described by the interfaces so we'd need a model.

Basically 1 is sort of essential to work in real projects (who uses ES3 still?), 2 is more of an enhancement.

@lbovet lbovet closed this as completed in 01e1c84 Feb 1, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants