Class inheritance in Spine about spine HOT 9 CLOSED

You should just take a look at inheritance in CoffeeScript - Spine uses
that.

Don't call ' parent:: constructor();' - call 'super'.

On Tue, Aug 16, 2011 at 11:05 AM, markprins <
[email protected]>wrote:

Hi,

I'm trying to work out how to correctly work with inheritance in Spine
Classes. However I think I am missing something and I couldn't find anything
about it in the documentation or tutorials on the web.

As a basic example in pseudocode I want to do something like this:

class Base {
constructor: function() {
this.foo = 'bar';
this.bar = 'woosh';
},
printContent: function() {
console.log(this.foo, this.bar);
}
}

class Extend extends Base {
constructor: function() {
parent:: constructor();
this.bar = 'blablabla';
}
}

i1 = Base();
i1.printContent(); // should print: bar woosh
i2 = Extend();
i2.printContent(); // should print: bar bladiebla

I have played around with the spine classes and did something like:

var Base = Spine.Class.create({
init: function() {
console.log('base init');
this.foo = 'bar';
this.bar = 'woosh';
},
dump: function() {
console.log('dump', this.foo, this.bar);
}
});
var Extend = Base.create({
init: function() {
console.log('extend init');
this.bar ='bladiebla';
},
dump2: function() {
console.log('dump2', this.foo, this.bar);
}
});
base = Base.init();
base.dump();
extend = Extend.init();
extend.dump2();

This results in:
base init
dump bar woosh
extend init
dump2 undefined bladiebla

Apparently this is not the approach to take in Spine. Although I think i'm
pretty close (the functions seem to inherit correctly, but the proper tie
settings are not.

Can you help out a bit?

Kind Regards,

Mark

Reply to this email directly or view it on GitHub:
https://github.com/maccman/spine/issues/95

Alex MacCaw

+12147175129
@maccman

http://alexmaccaw.co.uk | http://www.leadthinking.com | http://socialmod.com

from spine.

Hi Maccman,

Am I right in thinking you have abandoned your original prototypal inheritance setup for class properties? The following looks like it just copies the class methods/properties when inheriting:

for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; }

I liked the output that your old implementation gave in the console (see second FAQ: http://maccman.github.com/spine/#h-faq), it's now difficult to inspect "classes" that way... is there a new way inspecting classes?

Thanks,

Jamie

from spine.

Yes, it's a shame, liked the old way too. However, CoffeeScript's syntax has
too many advantages not to use. Unfortunately there's not a way to see the
prototype tree for class properties.

On Sat, Sep 10, 2011 at 12:03 PM, Jamie Hill <
[email protected]>wrote:

Hi Maccman,

Am I right in thinking you have abandoned your original prototypal
inheritance setup for class properties? The following looks like it just
copies the class methods/properties when inheriting:

for (var key in parent) { if (__hasProp.call(parent, key)) child[key] =
parent[key]; }

I liked the output that your old implementation gave in the console (see
second FAQ: http://maccman.github.com/spine/#h-faq), it's now difficult to
inspect "classes" that way... is there a new way inspecting classes?

Thanks,

Jamie

Reply to this email directly or view it on GitHub:
https://github.com/maccman/spine/issues/95#issuecomment-2058946

Alex MacCaw

+12147175129
@maccman

http://alexmaccaw.co.uk | http://www.leadthinking.com | http://socialmod.com

from spine.

Oh, that's a shame... I'm still not won over by CoffeeScript even though I've been writing Ruby for 5+ years. How about trying to get your class system adopted by CoffeeScript as it's by far the cleanest solution I've come across.

from spine.

Unfortunately there are some caveats to it, that I don't think the
CoffeeScript crowd would like:

a) You can't use the 'new' keyword
b) It's a little slower

What I'd like to push for in the CS community is a way of easily extending
the interpreter so you could 'plugin' language features like these advanced
classes.

On Sat, Sep 10, 2011 at 1:28 PM, Jamie Hill <
[email protected]>wrote:

Oh, that's a shame... I'm still not won over by CoffeeScript even though
I've been writing Ruby for 5+ years. How about trying to get your class
system adopted by CoffeeScript as it's by far the cleanest solution I've
come across.

Reply to this email directly or view it on GitHub:
https://github.com/maccman/spine/issues/95#issuecomment-2059192

Alex MacCaw

+12147175129
@maccman

http://alexmaccaw.co.uk | http://www.leadthinking.com | http://socialmod.com

from spine.

Surely the new keyword thing isn't an issue as CS could just compile to use .init() everywhere instead? ...the ability to plugin language features would be cool.

from spine.

I'm a stickler for syntax and consistency. I for one think

var person = new Person();

reads nicer than

var person = Person.init();

Plus, I think it's awkward in a large app made up of many libs that some code uses new and some init. I'd prefer one consistent standard across all libraries and I think new is pretty much the norm.

On that note, am I understanding this thread correctly... instantiating Spine classes/models would work fine with new and have no odd side effects?

from spine.

miana: correct :)

from spine.

@maccman Thought you might be interested in this with regards extending the CoffeeScript class system: jashkenas/coffeescript#1762

from spine.