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

Decorators #974

Closed
andreypopp opened this issue Mar 8, 2015 · 25 comments
Closed

Decorators #974

andreypopp opened this issue Mar 8, 2015 · 25 comments
Labels

Comments

@andreypopp
Copy link

@andreypopp andreypopp commented Mar 8, 2015

As I understand, decorators are going to be suggested to TC39. I also think they are useful for higher-order React components.

Example:

// decorator is a function
function annotation(target) {  
   // Add a property on target  
   target.annotated = true;  
}

// its usage
@annotation  
class MyClass { } 

// compiles to something like
class MyClass {}
MyClass = annotation(MyClass)
@andreypopp

This comment has been minimized.

Copy link
Author

@andreypopp andreypopp commented Mar 8, 2015

Seems like TypeScript also plans to implement them. microsoft/TypeScript#2249

@sebmck

This comment has been minimized.

Copy link
Contributor

@sebmck sebmck commented Mar 8, 2015

Are you requesting they be implemented now or enquiring if they will be once they've got a stable spec?

@andreypopp

This comment has been minimized.

Copy link
Author

@andreypopp andreypopp commented Mar 8, 2015

@sebmck yes, this is a feature request.

@sebmck sebmck added the enhancement label Mar 9, 2015
@sebmck

This comment has been minimized.

Copy link
Contributor

@sebmck sebmck commented Mar 9, 2015

@andreypopp Yup, I have every intention of implementing them. Waiting on the next TC39 meeting where they'll be presented (~2 weeks away!) and then hopefully I can gauge their stability (there are currently a bunch of changes planned AFAIK).

@truongsinh

This comment has been minimized.

@jayphelps

This comment has been minimized.

Copy link
Contributor

@jayphelps jayphelps commented Mar 10, 2015

I'm anxiously awaiting too

omg

@zloirock

This comment has been minimized.

Copy link
Member

@zloirock zloirock commented Mar 10, 2015

Private fields (will be discussed in next tc39 meeting) conflict with decorators - uses the same syntax.

@domenic

This comment has been minimized.

Copy link

@domenic domenic commented Mar 13, 2015

@zloirock false, they both use an @ sign, but there is no syntax conflict.

@zloirock

This comment has been minimized.

Copy link
Member

@zloirock zloirock commented Mar 13, 2015

@domenic I do not see the difference: class method declaration, private fields.

@domenic

This comment has been minimized.

Copy link

@domenic domenic commented Mar 13, 2015

@zloirock the decorators appear on top of a method declaration; the private fields do not.

@zloirock

This comment has been minimized.

Copy link
Member

@zloirock zloirock commented Mar 13, 2015

@domenic I do not understand. In the examples I see it:

class Class {
  @privateField;
  @decorator
  method(){}
}
@domenic

This comment has been minimized.

Copy link

@domenic domenic commented Mar 13, 2015

Yes, that works just fine. It declares a private field named privateField and applies the decorator decorator to method.

@zloirock

This comment has been minimized.

Copy link
Member

@zloirock zloirock commented Mar 13, 2015

@domenic i.e. the only difference is the presence of semicolons? Their joint application will make code unreadable and will cause a lot of bugs.

@domenic

This comment has been minimized.

Copy link

@domenic domenic commented Mar 13, 2015

I disagree.


From: Denis Pushkarevmailto:notifications@github.com
Sent: ý2015-ý03-ý13 15:33
To: babel/babelmailto:babel@noreply.github.com
Cc: Domenic Denicolamailto:d@domenic.me
Subject: Re: [babel] Decorators (#974)

@domenichttps://github.com/domenic i.e. the only difference is the presence of semicolons? Their joint application will make code unreadable and will cause a lot of bugs.


Reply to this email directly or view it on GitHubhttps://github.com//issues/974#issuecomment-78831483.

@sebmck

This comment has been minimized.

Copy link
Contributor

@sebmck sebmck commented Mar 13, 2015

In a language with ASI relying on semicolons to distinguish declarators and private methods is dangerous.

@wycats

This comment has been minimized.

Copy link

@wycats wycats commented Mar 13, 2015

We definitely will need to work out apparent syntactic conflicts between private fields and decorators. This is why we can't simply ship features one at a time, but need to vet them as a whole.

The JavaScript Decorators proposal I plan to present to TC39 in Paris is at https://github.com/wycats/javascript-decorators. I will be working with @zenparsing ahead of that meeting to see what we can come up with that won't conflict but still be possible to prototype in the short term via babel.

(Incidentally, this decorators proposal has been percolating in various forms for several years, but this is the first time a complete formal proposal will be presented.)

@wycats

This comment has been minimized.

Copy link

@wycats wycats commented Mar 13, 2015

At minimum, trying to use @ syntax for both in class bodies is visually very confusing.

@domenic

This comment has been minimized.

Copy link

@domenic domenic commented Mar 13, 2015

Yeah, it's confusing, no disagreement there. Just saying that there's no conflict that would prevent both from being implemented as-is.

@zenparsing

This comment has been minimized.

Copy link
Contributor

@zenparsing zenparsing commented Mar 13, 2015

As @wycats mentioned, we're working together now on this intersection. Unfortunately, we're designing within a very constrained syntactic space, but that's all part of the fun. : )

@sebmck sebmck modified the milestone: 4.8.0 Mar 15, 2015
@sebmck

This comment has been minimized.

Copy link
Contributor

@sebmck sebmck commented Mar 24, 2015

A complete implementation will be available in the next major behind the experimental flag. It's not recommended for production use as breaking changes may be introduced without bumping majors in order to track the proposal as it develops.

@sebmck sebmck closed this Mar 24, 2015
@truongsinh

This comment has been minimized.

Copy link

@truongsinh truongsinh commented Mar 25, 2015

@sebmck so is it available from master already?

@sebmck

This comment has been minimized.

Copy link
Contributor

@sebmck sebmck commented Mar 25, 2015

@truongsinh No, I try not to do unstable development on the master branch. It's available in the experimental branch which is undergoing a lot of development in preparation for 5.0.0.

@truongsinh

This comment has been minimized.

Copy link

@truongsinh truongsinh commented Mar 25, 2015

Thanks, I think I'll try in the experimental branch

@truongsinh

This comment has been minimized.

Copy link

@truongsinh truongsinh commented Mar 25, 2015

@sebmck which commit is it btw?

@sebmck

This comment has been minimized.

Copy link
Contributor

@sebmck sebmck commented Mar 25, 2015

@truongsinh e04ecc7, daecec2 and others.

@lock lock bot added the outdated label Jul 24, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Jul 24, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
8 participants
You can’t perform that action at this time.