Proposal: allow super in object literals

[aleclarson]

As seen on MDN.

obj1 = ->
  method1: ->
    console.log 'method1'

obj2 =
  method2: ->
    super.method1()

Object.setPrototypeOf obj2, obj1
obj2.method2() # logs "method1"

The obj2 variable would transpile to:

obj2 = {
  method2() {
    super.method1();
  }
};

[GeoffreyBooth]

Any thoughts @connec or @helixbass ?

[connec]

I didn't realise that was valid 😄 I don't see any reason not to support it.

[aleclarson]

Should all methods in object literals transpile to foo() {} with this change? Or only if super is used?

[GeoffreyBooth]

Should all methods in object literals transpile to foo() {} with this change? Or only if super is used?

I see no reason not to use the method (foo() {}) syntax all the time, that’s what we do for classes. It’s also more concise, and it’s the form that MDN uses in their example.

@aleclarson are you up for implementing this in a PR?

[aleclarson]

I'm not familiar with the architecture, and have no time to learn it currently. 😢

[GeoffreyBooth]

Alright, anyone else? @connec ?

[joallard]

Okay, I'm trying to see how this could be done, but it seems like Code#isMethod could be of help here.

I haven't been able to test it out or see how it would get compiled in the context of an object.

[GeoffreyBooth]

I think isMethod in the context of Code determines whether to output as fn() {} (method style syntax) or fn = function() {} (traditional style, with function keyword). So it would need to be in Object probably that sets isMethod to be true on one of Object’s properties that is a function.

[joallard]

Here's where I'm at right now: https://gist.github.com/joallard/ff34ca6c31db0db7f214d4c199d6ebec

There seems to be a bad infinite-loop bug with Code#isStatement(). I have not figured out how Class#addInitializerMethod manages to do it.

[GeoffreyBooth]

So first off, you want to be editing nodes.coffee, not nodes.js. See https://github.com/jashkenas/coffeescript/wiki/%5BHowTo%5D-Hacking-on-the-CoffeeScript-Compiler

[vendethiel]

The edit to the .coffee is below in the diff

[joallard]

@GeoffreyBooth Yes, of course, but I preferred editing nodes.js directly and test than nodes.coffee, then rebuild, wait, then test.

I read the wiki post forwards and backwards, but there's not much currently on the workflow, I've had to hack things and figure them out.

I still can't manage (or have invested the time) to break out a Repl in the middle of code, so I'm down to console-logs. I'll try to add some contrib-workflow tips to the wiki with the things I've learned along the way.

But obviously, a PR wouldn't be so hacky.

[GeoffreyBooth]

Sorry I didn't look closer. You might want to review https://github.com/jashkenas/coffeescript/wiki/%5BHowTo%5D-How-parsing-works, that provides an overview.

Getting debugging working in Node is well worth the time. Basically create a test.coffee with very minimal code, like one object with one method, at the root of the CoffeeScript repo. Then run:

node --inspect-brk ./bin/coffee -bp ./test.coffee

And open Chrome DevTools and connect to the Node debugger. You can step through Node code the same as using DevTools for frontend code.