CS2 Discussion: Output: Classes #4922
Comments
|
From @kirly-af on 2016-08-07 13:36 This is discussed in jashkenas/coffeescript#4233 (and probably many others I'm not aware of). Also, I just discovered this Redux PR thanks to @GeoffreyBooth which looks REALLY promising. |
|
From @GeoffreyBooth on 2016-08-10 07:04 So it appears that someone has actually already implemented CoffeeScript |
|
From @DomVinyard on 2016-08-15 15:16 I think there's probably a larger conversation to be had about decaffeinate specifically, how and where it intersects with this project, what can be borrowed, what can be adapted, etc. |
|
From @alangpierce on 2016-08-21 02:06 Hi, I'm a decaffeinate contributor. While decaffeinate does have basic support for classes, full support is one of the main missing features right now. I'm hoping to improve it over the next few weeks, but it's definitely a challenge, since my understanding is CoffeeScript allows arbitrary code in class bodies, while ES2015 classes only allow methods. Decaffeinate also compiles CoffeeScript class fields to the public class fields proposed feature (currently stage 2), but even that has pretty significant semantic differences that have caused bugs for me (CS class fields are on the prototype, JS class fields are assigned to the instance once the constructor finishes). Anything other than methods or fields causes decaffeinate to crash. |
|
From @GeoffreyBooth on 2016-08-21 02:28 Thanks @alangpierce. Yeah, after looking at it more I think the better solution is to redefine the While the immediate focus is on adding support to CoffeeScript for missing vital ES2015 features (modules, classes), the longer-term goal especially of coffeescript6 is to update CoffeeScript’s output to use more of the latest standards. This essentially means we would be doing the work that decaffeinate is doing, but within the main CoffeeScript compiler. I skimmed through the decaffeinate repo, hoping to find some commits that highlight what differences it had from the main CoffeeScript compiler, but I couldn’t make sense of it. Do you mind giving whatever overview you can of how decaffeinate works, and where I should look for code that might be useful to repurpose in the main CoffeeScript compiler? For example, where is the code that generates an ES2015 class? |
|
From @mrmowgli on 2016-08-21 06:38 I would love to see some way of extending the current class functionality to generate the ES2015 code, and then decorate with everything else. I guess I don't really understand what actually breaks and where yet though. I am assuming that ES classes have extra restrictions, ie that they aren't just objects with prototypes set in a specific pattern? From the Babel overview:
So I would think we could construct functions only, then decorate with everything else? |
|
From @alangpierce on 2016-08-21 07:00 @GeoffreyBooth Yep, dropping support for code in class bodies makes a lot of sense for your case. Sure, I can give a quick overview of how decaffeinate works: Unfortunately, I think the short answer is that decaffeinate's approach is pretty different from the CoffeeScript compiler, so you may not be able to use much code/logic. From my reading of the CoffeeScript compiler, it parses the input to an AST, then calls the recursive A little more information on how decaffeinate is structured: it consists of five "stages" (one CoffeeScript -> CoffeeScript, one CoffeeScript -> JavaScript, and three JavaScript -> JavaScript), the most important of which is the CoffeeScript -> JavaScript stage, which is called MainStage. For that stage, every type of AST node corresponds to a Patcher class. Each Patcher is a class that knows what kind of modifications to make to transform that type of CoffeeScript node to JavaScript. Here's a repl link that has some examples of what happens in different stages. You can change the "run to stage" selection to see the intermediate result after each stage (or intermediate lexer/parser results). I actually haven't worked with the class generation code, but was able to mostly figure out how things work. If you look at the decaffeinate-parser output for your example, you can see that the main AST hierarchy is Also, here's a writeup with some more details: Hope that helps! |
|
From @GeoffreyBooth on 2016-09-05 21:02 I don’t think we can simply redefine the How about this approach: we create a new CoffeeScript keyword, With Introducing a new keyword that wasn’t previously reserved is a breaking change, so we would need to introduce a flag. I think since
We could even add support for making Conversely, it might be a good idea to introduce What do you all think? @lydell, @rattrayalex, @JimPanic, others . . . |
|
From @JimPanic on 2016-09-06 05:54 I like the idea of Apart from that, I think the only solution to introduce this to users is a) with conversion tools and b) through a process of deprecation warnings, deprecation and removal over several releases. This is something we have to plan, no matter what keywords we use in the end. The only thing that could be dangerous is to keep the |
|
From @lydell on 2016-09-06 05:55 Here's my vote: Add Release it by bumping the middle version number, keeping CoffeeScript's current versioning scheme of bumping the middle number when there are new features an slightly-but-not-very breaking changes. (As @GeoffreyBooth it is very unlikely that this will cause any trouble for anyone.) No CoffeeScript 2.0.0: Remove old |
|
From @GeoffreyBooth on 2016-09-06 05:58 I guess we probably don’t need a flag if we’re simply adding My god, did we just come up with a way to implement classes without a flag? 😛 |
|
From @JimPanic on 2016-09-06 06:23 I think we did, yes. 🤔 I'm also very much in favour of implementing semver. |
|
From @greghuc on 2016-09-06 08:20 I like the idea of a separate At present Example: |
|
From @lydell on 2016-09-06 11:21 @greghuc I don’t really see the step backwards? # ClassExample.coffee
CONSTANT_EXAMPLE = 'I am a constant example'
privateStaticFunction = -> console.log 'I am a private static function'
export class ClassExample
constructor: -> console.log 'I am a constructor'
instanceFunction: ->
console.log '[start] I am an instance function'
console.log CONSTANT_EXAMPLE
privateStaticFunction()
@constructor.staticFunction()
console.log '[end] I am an instance function'
@staticFunction: ->
console.log '[start] I am a static function'
console.log CONSTANT_EXAMPLE
privateStaticFunction()
console.log '[end] I am a static function'
# whatever.coffee
import {ClassExample} from 'ClassExample.coffee'
ClassExample.staticFunction()
(new ClassExample).instanceFunction() |
|
From @greghuc on 2016-09-06 11:48 @lydell I'm still getting up to speed with ES6 features, so please take my comments with a pinch of salt.. Your example code isn't that bad. It is essentially forcing a coffeescript user to have a closure wrapping both the class declaration and the private 'constant' and static function, to ensure private means private. But from my quick scan of ES6 modules, I suppose there's an implicit closure when importing a module from a file. I could live with this, although I don't think your example code is as clean or explanatory as the current coffeescript code. In the current code, the class acts as an encapsulating namespace for all private and public functions. For the |
|
From @DomVinyard on 2016-09-06 15:02 How about, instead of |
|
From @lydell on 2016-09-06 15:08 @DomVinyard In my opinion that would be very confusing. I also think that that will break more people's code – even CoffeeScript's source code has |
|
From @DomVinyard on 2016-09-06 15:24 @lydell I concede that point and do accept it would break more projects than |
|
From @GeoffreyBooth on 2016-09-08 03:46 @DomVinyard I have to agree with @lydell on this one. I’m not thrilled by the name So I think the next step is to define what the syntax of
Here’s an extensive example. It seems clear from the examples that we will need to implement I think like with modules, our goal should be to simply create a way to output ES classes with all their features as they are, rather than trying to improve upon them the way that the original Is anyone else interested in helping research/define this, and/or code it? |
|
From @rattrayalex on 2016-09-08 04:27 Exciting stuff. Perhaps once I am curious though – what advantages do CS classes have over ES classes? Why would a developer prefer CS to ES output? (Honestly don't know). |
|
From @JimPanic on 2016-09-08 08:29 @rattrayalex ES201x classes cannot have executable code in their bodies. You cannot declare properties at runtime. You can do that with CS classes but I personally think it's bad practice to do so as it's not very explicit and mixes different styles of defining "types". |
|
From @JimPanic on 2016-09-08 08:39 Ok let me rephrase that a bit: of course you can declare properties at runtime, but not in the class declaration body like in CS. :) |
|
From @greghuc on 2016-09-08 08:54 Re-reading through this 'classes' thread, I think it's worth noting that are at least three distinctive positions to take on Coffeescript and ES6 classes. Two positions are at odds with one another. The positions:
My personal position is a combination of 1 and 3: change the Coffeescript compiler to take advantage of ES6 class functionality, and fix any technical incompatibilities. But don't change (or remove!) existing CS class semantics. I see position 2 as a risky one (Coffeescript classes are semantically wrong, now that ES6 classes have come along). This path leads to the ES6 tail wagging the Coffeescript dog. From now on, Coffeescript is no longer an opinionated "little language that compiles into JavaScript". Instead, we'll be continually playing catchup, discussing the best way to implement the newest EcmaScript feature in Coffeescript syntax. In essence, it will be Ecmascript committees driving the core direction of Coffeescript, not the Coffeescript committers themselves. Already, because ES6 classes don't currently support data properties, we might have to remove Coffeescript class data properties. What happens when Ecmascript adds them back in? |
|
From @lydell on 2016-09-08 09:19 @greghuc The biggest problems, in my opinion, are that you currently cannot extend an ES2015+ class (#4233) and that CoffeeScript’s |
|
From @greghuc on 2016-09-08 12:19 Also, to put a slight dampener on 'ES6 classes are the new awesome', here's a link to a curated list of resources on why ES6 (aka ES2015) classes are NOT awesome. I'm not aiming to start an argument over the pros and cons of ES6 classes. However, it's worth keeping in mind that ES6 classes are a new and unproven technology, and it's unclear how things will play out with them. This is independent to how well ES6 classes are supported by browsers and nodejs. This raises the possibility of Coffeescript nextgen locking itself to a feature that doesn't stand the test of time. It doesn't preclude Coffeescript being able to interoperate with ES6 classes. |
|
From @GeoffreyBooth on 2016-09-11 18:08 @greghuc I think your preferred approach (1 and 3) is what the What your “data properties” example illustrates, however, is that we should think long and hard before we add any sugar over I don’t think it’s so bad to follow ECMA. They’re moving way faster than we ever could. It’s not a bad thing to keep up with the JavaScript world. |
|
From @GeoffreyBooth on 2016-09-14 03:14 I’ve been thinking about how Decaf manages to parse most CoffeeScript classes into ES2015 Out of curiosity I ran Decaf on It’s another question whether these ES2015 Assuming we wouldn’t use Decaf but would reimplement similar logic ourselves, is this an approach we want to take? |
|
From @kirly-af on 2016-09-14 14:14 To be honest, I'm not so sure what are the exact points where CS classes and ESnext classes clash. Another issue is this. However, this suggestion looks good to me. |
|
From @mrmowgli on 2016-10-02 09:32 Still going through everything, but I ran into this reference of Node class support and versions. Handy reference: http://node.green/#class |
|
From @connec on 2016-10-03 13:34 I got a bit carried away "adding some [tests] to exercise the ordering" and created a WIP PR @ #4330. I don't intend for this to clash with anything anyone else is doing, but hopefully it can highlight some of the potential issues and pitfalls. Some salient points:
|
|
From @svicalifornia on 2016-10-23 12:45 Another way that ES6 classes (at least as compiled to ES5 by Babel) differ from CS classes is that in ES6, an Cross-post from #4330: When using Objection.js Model with CoffeeScript, I had to add a line of boilerplate after each CS subclass definition to call Model's Babel compiles ES6 subclasses in such a way that the hook was called in the resulting ES5 code, so the explicit (and redundant) call to To achieve backward compatibility with CS code and derive from classes in ES libraries, it would be great if CS 1.x could detect and extend ES6 classes as follows:
Going the other direction — compiling CS classes to ES6 classes that can be extended by ES6 code — would be a breaking change and should probably be held for 2.0. (Extending from CS to ES subclasses is the much less common use case, given that most of the ES community doesn't care much for CoffeeScript. At least until CoffeeScript is modernized to full ES compatibility, we are much more likely to want to use ES classes than they are likely to want to use modules originally written in CoffeeScript.) If CS 1.x generates CS subclasses, and CS 2.0 generates ES classes and subclasses, then I agree with @jashkenas that a separate |
|
From @GeoffreyBooth on 2016-10-26 06:10 Trying to push along #4330: can anyone write a test that, if it were to pass, would prove that CoffeeScript could extend a React class such that CoffeeScript can interoperate well with React? As far as I can tell the big interoperability concern with classes is that ES classes cannot currently be extended in CoffeeScript; and the most high-profile case where this is an issue is React. I would love a failing test where, if we were to get it to pass, it would prove that our interoperability problem with React was solved. Please don’t write the test such that it actually imports React, just create the simplest possible ES class to demonstrate the issue. There could be a |
|
From @mitar on 2016-12-11 20:33 I really love how CoffeeScript has classes and I do not really have much opinion on to what is it compiled internally. But I do love one thing from ES6 classes: that you can define instance properties inside the class body. I love that: Is compiled to: Because otherwise doing an instance-based assignment you can do only inside a constructor, which sometimes makes it much less cleaner to read. I wanted this feature so many times, and on the other hand I have never seen a need for executable class bodies which I could not simply resolve with creating dynamic classes at runtime. |
|
From @lydell on 2016-12-12 06:07
That's not ES6, but a proposal for a future specification. |
|
From @mitar on 2016-12-12 06:11
Oh, sorry. It works with Babel, so I just assumed it is part of E2016 already. Do you know which Babel rule it is/more about this proposal/its name? In any case, I love this feature and I would propose that CoffeeScript has it even it does not become part of JavaScript. Edit: found it: https://babeljs.io/docs/plugins/transform-class-properties/ |
|
From @GeoffreyBooth on 2016-12-12 06:47 See also: #4354 (comment) |
|
From @mrmowgli on 2016-12-16 07:57 Ok, I have finished getting through the existing class tests, and a lot of the current rules are covered well. I will be adding roughly thirty or so tests. One thing was very "interesting" to me: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/species It's definitely referred to in the core MDN docs, and Symbols are an area we will probably have to support in iterators and classes. I'm not entirely sure I understand why this exists, if anyone knows I would love to hear a use case? class C {
ident() {return 'Class C!';}
};
class MyArray extends Array {
// Overwrite species to the parent Array constructor
static get [Symbol.species]() { return C; }
ident() {return 'Class MyArray!';}
}
var a = new MyArray(1,2,3);
var mapped = a.map(x => x * x);
console.log(mapped instanceof C); // true
console.log(mapped instanceof MyArray); // false
console.log(mapped instanceof Array); // false
console.log(MyArray.prototype); // MyArray
console.log(a.ident()); // Class MyArray!
console.log(mapped.ident()); // Class C!
console.log(mapped); // C { '0': 1, '1': 4, '2': 9 } |
|
From @triskweline on 2016-12-16 08:08 I found this article slightly more helpful than MDN: |
|
From @GeoffreyBooth on 2016-12-16 08:20
You, sir, are my hero. |
|
From @mrmowgli on 2016-12-16 08:24 Also
and likely more that I don't know about yet. Almost all of the tests for classes would need to be rewritten if I have no idea what @connec is putting together for super, but I suspect the final version will be split between generating the "official" CS6 when |
|
From @mrmowgli on 2016-12-16 08:35 @henning-koch - Interesting article. I suspect Symbol.species in this format will end up being used quite a bit. Which means that we probably need to add get/set fairly soon to classes. |
|
From @connec on 2016-12-16 11:57 @mrmowgli regarding Firstly, the way Context.name = -> super # doesn't compile
Context.prototype.name = -> super # super reference: Context.__super__.name
class Context then @name = -> super # super reference: Context.__super__.constructor.name
class Context then name: -> super # super reference: Context.__super__.name
# constructor is not special
Context.prototype.constructor = -> super # super reference: Context.__super__.constructor
class Context then constructor: -> super # super reference: Context.__super__.constructorIn #4354 (the active ES class PR) the only change for class Context then constructor: -> super # super reference: superOrdinarily, the "super reference" is compiled with a
That is an interesting case indeed. The way I chose to handle it in my PR is to add an implicit class A
class B extends A then constructor: ->
# ...
# class B extends superClass {
# constructor() {
# super(...arguments);
# }
# }
# ...
class A
class B extends A then constructor: -> super()
# ...
# class B extends superClass {
# constructor() {
# super();
# }
# }
# ...The reason I chose to do this is because it's the most reasonable way I could think of to deal with class B extends A
constructor: (@name) ->
greet: ->
console.log "Hi #{@name}"
class C extends A
constructor: (name) ->
super()
@name = name
greet: =>
console.log "Hi #{@name}"Without an implicit class B extends A {
constructor (name) {
this.name = name
// super() - this is already too late
}
}
class C extends B {
constructor (name) {
this.greet = bind(this.greet, this)
super() // - this is also too late
}
}Given these cases, there are basically 3 options:
I went with an extension of 3., and decided to add an implicit |
|
From @connec on 2016-12-16 12:09 Sorry for the wall of text! Figured I'd try and explain the current status as fully as I could. Having written that all out, I'm starting to feel like option 2. should be explored a little more. I guess the idea behind that would be to generate code that made it seem like // class A
// class B extends A
// constructor: (@foo) ->
// console.log super(), @foo, @bar
// bar: =>
class A {}
class B extends A {
constructor (foo) {
var ref;
console.log((ref = super(), this.foo = foo, this.bar = this.bar.bind(this), ref), this.foo, this.bar)
}
bar () {}
}This would behave reasonably well I think, as attempting to access |
|
From @mrmowgli on 2016-12-17 04:25 Ok, my bad: Super CAN be called in other methods, and var A = class A {
constructor (token) {
this.token = token;
console.log('Token in base was: ', token);
}
objectLocal(origin) {
console.log('The '+ origin + ' called in Parent method.');
}
}
var B = class B extends A {
constructor (token){
super(token);
this.token = token;
console.log('Secondly, token `'+ this.token + '` was called in child.');
}
objectLocal() {
console.log('Overriding objectLocal now with "super"');
console.log('Current token: ' + this.token)
super.objectLocal(this.token)
}
}
let n = new B('coffee-script');
n.objectLocal();
/* Output:
Token in base was: coffee-script
Secondly, token `coffee-script` was called in child.
Overriding objectLocal now with "super"
Current token: coffee-script
The coffee-script called in Parent method.
*/ |
|
From @GeoffreyBooth on 2017-01-19 06:20 @connec @mrmowgli, fantastic heroic work on #4354. Now that that’s merged in, what work related to classes remains to be done? |
|
From @mrmowgli on 2017-01-19 11:17 I realize we didn't create browser specific tests, however I believe we are expecting Babel to cover the bases there. Other than that it seems like it's mostly edge cases surrounding super(), and those need actual usage to shake out a bit. I'm of the opinion we should go ahead with the release, the tests are comprehensive and everything works far better than I originally expected. @connec did an amazing job! Realistically I believe we should start trying to cover lower priority items like get/set, species, and new modifiers like |
|
From @connec on 2017-01-19 12:17 The only thing we probably want to finish off for Unless someone else picks it up I will work on this once I make some time. |
|
From @GeoffreyBooth on 2017-01-19 16:48 @mrmowgli the tests really only cover Node, aside from the browser-specific ones. We treat Node as more or less our reference JavaScript runtime to test against, for JavaScript features that should behave identically in Node and browser-based runtimes. @connec what do you mean by |
|
From @connec on 2017-01-19 17:05 CS source class Base
method: ->
console.log 'Base#method'
class Child extends Base
method: ->
super
console.log 'Child#method'Current CS2 output // Generated by CoffeeScript 2.0.0-alpha
var Base, Child;
Base = class Base {
method() {
return console.log('Base#method');
}
};
Child = (function(superClass) {
class Child extends superClass {
method() {
Child.__super__.method.call(this, ...arguments);
return console.log('Child#method');
}
};
Child.__super__ = superClass.prototype;
return Child;
})(Base);Desired CS2 output // Generated by CoffeeScript 2.0.0-alpha
var Base, Child;
Base = class Base {
method() {
return console.log('Base#method');
}
};
Child = class Child extends Base {
method() {
super.method(...arguments);
return console.log('Child#method');
}
};I could have time any day now 😄 Watch this space at the weekend... |
|
From @connec on 2017-01-19 17:13 There will be some 'tough choices' to make for this, I expect. I've not explored it much yet but if we wanted to clean up properly we would effectively lose our current support for Base = ->
Base::method = -> console.log 'Base#method'
Child = ->
Child extends Base
Child::method = ->
super
console.log 'Base#method'Some alternatives:
I'll flesh all these out a bit once I started looking at it. |
|
From @GeoffreyBooth on 2017-01-19 17:26 We already removed some tests that assumed a class was really a function (i.e. the pre-ES2015 When you get a chance, you should start documenting the class-related breaking changes in the wiki. You’re far more familiar with what’s changed than I am. |
|
From @jashkenas on 2017-01-19 17:26 ES6 Edit: Regardless — moving to ES6 classes for CS2 means that you take the lumps that come with. We should definitely not still have the original system still lying around in the codebase for the CS2 release. |
|
From @connec on 2017-01-19 17:53 Nope @jashkenas, it's a 'syntactic form' that is only valid within a class initializer. |
|
From @connec on 2017-01-19 17:55 I think it's interesting that we could opt to compile |
|
From @connec on 2017-01-19 18:44 Threw together #4424 with the bare bones. |
|
From @jashkenas on 2017-01-19 19:10
It's just madness. It straightjackets class construction unnecessarily, and makes ugly lots of interesting patterns for mixing methods into classes, or composing traits. One step forward, three steps back.
That seems like a pretty nice CoffeeScript feature that would improve upon ES6 classes. |
|
From @GeoffreyBooth on 2017-02-04 20:10 Closed via #4424. For further changes or improvements upon CS2 classes, please open new issues. |
From @rattrayalex on 2016-08-06 21:33
This is a core feature that we should rally around submitting to jashhkenas/coffeescript in the near term.
Does anyone know of current leading efforts to accomplish this in the community? Perhaps we can lend a hand there.
The text was updated successfully, but these errors were encountered: