fixes #841: bring back the extended hook

[michaelficarra]

I say we go for it.

[jashkenas]

Thanks for the implementation -- we should definitely decide this one way or another before 1.2.1, but let's not merge this quite yet...

[michaelficarra]

Of course.

[michaelficarra]

@jashkenas: we're going to need another release soon (a new minor version), so how are we going to handle this? I say we merge it.

[danielribeiro]

+1

[goomtrex]

Minus one.

[keithnorm]

+1

[nathansobo]

+1

[CodeMonkeySteve]

+10

[jashkenas]

I had a nice long chat with @wycats about Ember's need for the extended hook, and I'm afraid I persuaded myself that we shouldn't do it.

There are good arguments for running extended before the class body is defined -- to make functions that it adds to the class object available within the class body; and there are good arguments for running extended after the class body is defined -- in case it wants to iterate through the prototype and enhance properties of a certain kind. Given that both are valid use cases, I don't think we should do either. Instead:

class A extends B
  B.extended(this)
  ... class body ...


class A extends B
  ... class body ...
  B.extended(this)

... or many other possible uses of dynamic hooks during class definition. Hard-coding a single extended hook would add magic to our class semantics (above and beyond JS) while hiding the much more powerful abilities of executable class bodies and JavaScript exposed prototypes. I don't think it's worth it.

[michaelficarra]

I can accept that reasoning. Thanks for looking into this.

[wycats]

We also discussed the possibility of adding in a compiler hook so that it would be easier to maintain an Ember variant of CoffeeScript without forking the entire project.

Thoughts?

[michaelficarra]

@wycats: Like #1968? Be sure to read #1023 as well.

[grayrest]

My extended use case would also work with a compiler hook.

[jashkenas]

I think in this case you'd just want a finer-grained breakdown of the "class" compilation function in nodes.coffee ... then you'd have (ideally) a single function to override. It's not an "events" thing, I don't think.

[wycats]

I'd optimally want to be able to subclass the compiler and override some hooks, rather than try to do something with events.

[collin]

I'm doing some terribly awful things to coffeescript and "classes" https://github.com/collin/pathology

I would also like to be able to flip some switches and override the 'class' part of the compiler.

But I think it's potentially a recipe for sadness. Say if I want to use two libraries that need to compiler overridden in different incompatible ways.

What are the use cases for class extension hooks other than wrapping around the class body? I can see re-opening a class, but not much else.

[nathansobo]

What about beforeExtended and afterExtended to cover the two cases discussed above? As it stands users of my library will have to call @extended manually at the top of the class body, which isn't horrible but could be prettier.

[collin]

I think a better hook would be executeClassBody, which would be passed in a function to be executed as the class body.

This would allow for extensions that hook before extension, after extension and allow for re-opening of classes.

@jashkenas you mention other scenarios that you don't want to trample on, I'd like to know what those are in case I'm completely missing the boat on this.

[lancejpollard]

+10

Adding a compiler hook would be ideal so as to avoid creating a custom fork of coffeescript that does something like: https://gist.github.com/2365817.

[lancejpollard]

@jashkenas @wycats what do you think of this?

https://github.com/d4tocchini/coffee-script/blob/master/src/nodes.coffee#L1990
https://github.com/viatropos/tower/blob/873acd3191c1f7d42bb0bf555be0541dcc557670/test/cases/support/emberTest.coffee

Exploring a minimal set of hooks for extending CoffeeScript.

[d4tocchini]

Thanks @viatropos.

The extended hook was not enough for Ember compatibility. I added defineProperty, defineStaticProperty & extend hooks. Results in many atomic ember.reopen & ember.reopenClass, but it does the trick without screwing up lexographic ordering of methods executed in class bodies. Bottom-line, CoffeeScript & Ember should get along.

A more generalized mechanism for extending the compiler would be awesome.