Class system extendability - A simple solution

Hi,

The one thing keeping me from using CoffeeScript full-time is that it's class system cannot be extended in any way. Below is an idea that allows users to hook into the class system, it's very similar to that in Ruby and Spine.js.

I am suggesting that the following coffee script:

class Bar

class Foo extends Bar
  myInstanceMethod: -> console.log 'I am an instance method';
  @myClassMethod: -> console.log 'I am a class method';

Should generate:

var Bar, Foo;
var __hasProp = Object.prototype.hasOwnProperty, __extends = function(child, parent) {
  var mixin = function(target, obj) {
    for (var key in obj) { if (__hasProp.call(obj, key)) target[key] = obj[key]; } };
  mixin(child, parent);  
  function ctor() { this.constructor = child; }
  ctor.prototype = parent.prototype;
  child.prototype = new ctor;
  child.__super__ = parent.prototype;
  child.include = child.include || function(obj) { mixin(this.prototype, obj); };
  child.extend = child.extend || function(obj) { mixin(this, obj); };
  if (parent.inherited) parent.inherited(child);
  return child;
};
Bar = (function() {
  function Bar() {}
  return Bar;
})();
Foo = (function() {
  __extends(Foo, Bar);
  function Foo() {
    Foo.__super__.constructor.apply(this, arguments);
  }
  Foo.include({
    myInstanceMethod: function() {
      return console.log('I am an instance method');
    }
  });
  Foo.extend({
    myClassMethod: function() {
      return console.log('I am a class method');
    }
  });
  return Foo;
})();

This way, should Bar want to hook into the class system it could do the following:

class Bar
  @include: (obj) ->
    console.log "About to declare: '#{key}' on proto" for key in obj
    super

  @extend: (obj) ->
    console.log "About to declare: '#{key}' on class" for key in obj
    super  

class Foo extends Bar
  myInstanceMethod: -> console.log 'I am an instance method';
  @myClassMethod: -> console.log 'I am a class method';

I think this would make CoffeeScript's class system truly powerful and allow things like Ext's preprocessors... the applications are endless. The other benefit of this is that the resulting minified JS would be smaller due to the object notation used in include and extend. Obviously the include and extend function names are just a suggestion but I think the likeness to Ruby is a good thing. To avoid conflicts with existing code, they could always be __include and __exclude.

This tiny change also introduces Ruby-esque 'Modules' e.g.

CommonInstanceMethods =
  sharedFunction -> console.log 'I come from CommonInstanceMethods'

CommonClassMethods =
  sharedFunction -> console.log 'I come from CommonClassMethods'

class Foo
  @include CommonInstanceMethods
  @extend CommonClassMethods

class Bar
  @include CommonInstanceMethods
  @extend CommonClassMethods

I would create a patch but don't know enough about parsers to be able to implement it. I really hope we can add this as currently there is no way to extend the class system.

Thanks,

Jamie

One more thing... for ultimate flexibility the __extends function could call if (parent.inherited) parent.inherited(child) before returning child. This would allow a class to know when it has been inherited, again similar to Ruby.

[michaelficarra]

This doesn't necessarily need to be baked into the language. See https://github.com/jashkenas/coffee-script/wiki/Mixins for a quick and dirty example with similar goals. I do kind of like your suggestion, but I don't really like how it complicates coffeescript's extends semantics. Still, I give a very weak +1 for now.

[michaelficarra]

for ultimate flexibility the __extends function could call if (parent.inherited) parent.inherited(child) before returning child

@soniciq: we used to have this feature, in the form of the extended method. See #516 and #814, which is open right now specifically to bring it back. We could kill two birds with one commit right here.

@michaelficarra The Mixin example is possible however if your classes need to introspect property definitions etc, there is currently no way to achieve this.

I see what you mean about not wanting to complicate things but to be honest I actually think it makes thinks simpler... for the few extra bytes of additional output you get the ability to include instance properties, the ability to extend classes, the ability to extend the class system itself and smaller files when minified.

Here is an updated __extends function to include the 'inherited' callback:

var __hasProp = Object.prototype.hasOwnProperty, __extends = function(child, parent) {
  var mixin = function(target, obj) {
    for (var key in obj) { if (__hasProp.call(obj, key)) target[key] = obj[key]; } };
  mixin(child, parent);
  function ctor() { this.constructor = child; }
  ctor.prototype = parent.prototype;
  child.prototype = new ctor;
  child.__super__ = parent.prototype;
  child.include = child.include || function(obj) { mixin(this.prototype, obj); };
  child.extend = child.extend || function(obj) { mixin(this, obj); };
  if (parent.inherited) parent.inherited(child);
  return child;
};

Update: Also update original code.

[maccman]

Obviously a +1 from me :) - this would be awesome!

Would also help people compartmentalize and DRY their code by encouraging modules. It's a small change, but could have a big impact on how people write their CoffeScript.

[aemadrid]

+1 - seems a good trade-off.

[benjreinhart]

I think this is a great idea. I think it can be misleading when using the class keyword when really what I'm trying to do is modularize code, but yet I'm not planning on instantiating the class.

I think if this is done, it would be really cool to add a module keyword, just like ruby, which would be nice and readable.

[mythz]

Seems weird to overload '@' to mean class, In all other usages I thought it meant 'this', i.e. references the instance? What about 'class.' or the name of the Constructor i.e. Foo?

class Bar

class Foo extends Bar
  myInstanceMethod: -> console.log 'I am an instance method';
  class.myClassMethod: -> console.log 'I am a class method';
  Foo.myClassMethod: -> console.log 'I am a class method';

[michaelficarra]

@mythz: that has nothing to do with this issue. The context of a class body is the class itself, not the instance. I don't particularly agree with it, but it's the way it is. The class name can also be used, as you suggested. This issue proposes adding the include and extend methods to the constructors of classes that extend other classes.

Now that I think about it, classes won't have include and extend methods unless they're extending a superclass. @soniciq: how do you propose we overcome this inconsistency?

@mythz This is how CoffeeScript works currently, the '@' is a shortcut to 'this.'.

@ALL Right, now we have a few +1's, does anyone know how to go about getting this into CoffeeScript. I've had a look at the code with a view to implement the change but it's all scary parser stuff and I'm not really sure where to start... I will continue to investigate but if anyone else wants to chip in, please do.

[maccman]

@soniciq: @michaelficarra raises a good point, which needs to be addressed before we can go any further. If the class doesn't extend another class, than all that extra super and inheritance code won't be generated - not sure how we get round that.

@michaelficarra and @maccman Sorry missed your comment while writing my last one. That is a good point, I think I have a solution though... give me 15 to whip it up.

Right, here is a basic implementation, I'm working on cleaning it up a little. Note that the include and extend assignment only happens for classes that don't inherit another class as they will be copied by __extends to subclasses.

For the CoffeeScript:

class Foo
  myInstanceMethod: -> console.log 'Instance method'
  @myClassMethod: -> console.log 'Class method'

class Bar extends Foo
  myInstanceMethod: -> console.log 'Instance method'
  @myClassMethod: -> console.log 'Class method'

The following would be generated (you can copy this into a js console and include/extend Foo and Bar ):

var Bar, Foo;
var __hasProp = Object.prototype.hasOwnProperty,
    __mix = function(target, obj) {
      for (var key in obj) { if (__hasProp.call(obj, key)) target[key] = obj[key]; } },
    __extends = function(child, parent) {
  __mix(child, parent);
  function ctor() { this.constructor = child; }
  ctor.prototype = parent.prototype;
  child.prototype = new ctor;
  child.__super__ = parent.prototype;
  if (parent.inherited) parent.inherited(child);
  return child;
};
Foo = (function() {
  function Foo() {}
  Foo.include = function(obj) { __mix(this.prototype, obj); };
  Foo.extend = function(obj) { __mix(this, obj); };
  Foo.include({
    myInstanceMethod: function() {
      return console.log('Instance method');
    }
  })
  Foo.extend({
    myClassMethod: function() {
      return console.log('Class method');
    }
  });
  return Foo;
})();
Bar = (function() {
  __extends(Bar, Foo);
  function Bar() {
    Bar.__super__.constructor.apply(this, arguments);
  }
  Bar.include({
    myInstanceMethod: function() {
      return console.log('Instance method');
    }
  })
  Bar.extend({
    myClassMethod: function() {
      return console.log('Class method');
    }
  });
  return Bar;
})();

[michaelficarra]

A little problem:

class Foo
  @include: ->
  oops: ->

You don't need to compile to Foo.include or Foo.extend in the constructor, just compile to Foo.prototype.X = and Foo.X = and you won't have that problem. I'm going to be a weak -1 on this, though, since I don't want those methods cluttering up every constructor.

@michaelficarra compiling to Foo.prototype.X = and Foo.X = defeats the object as you then still can't intercept to property definition if you need to. As for cluttering up the constructor, I see what you mean but the benefit is huge... Ruby has had include and extend forever and they've not gotten in the way.