Thanks for the link!

Michael,

Thanks for sharing! There are some interesting things in there, although my preferred approach is the native prototype syntax for readability, code handover and for being there native in the language without dependencies.

var Human = MG.Class.Create({
Gender: null,
constructor: function(gender) {
this.Gender = gender;
},

GenderString: function() {
return this.Gender == ‘F’ ? “female” : “male”;
},

ToOverride: function() { return “Called from Human”; }
}, null, null);

var Individual = MG.Class.Create({
Unique: null,
constructor: function(unique) {
this.Unique = unique;
},

IsUnique: function() {
return this.Unique ? “Yes” : “No”;
},

ToOverride: function() { return “Called from Individual which is ” + (this.Unique ? “unique” : “not unique”) + ” / ” + this.base(); }
}, Human, null);

var objHuman = new Human(“F”);
var objIndividual = new Individual(true, “M”);

In my opinion also a check for parameters of the base constructor should be added. If the derived object does not provide on instantiation the correct number or parameters for the base, then an exception should be triggered.

http://www.extjs.com/blog/2009/11/11/advanced-plugin-development-with-ext-js/

Not sure how much you care about extjs, but the one of his points is that added functionality through subclassing prohibits the reuse of that functionality in other classes:

I’d like to correct/clarify my statement in the article: I definitely believe there is need and use for inheritance, what I was going for is that probably isn’t need to be in the fashion it is with class-based models (i.e. “super”-calling etc).

Thanks for the code, it was interesting!

At the end of the day, though, I think we all need to consider what we need and what till be our best way to do it: there’s no golden solution for any situation.

Enough of that, let’s talk about your approach to using inheritance. This approach suffers from a problem. What if your base class requires parameters to be initialized? Even worse, what if there are side effects to the base class being instantiated? You can’t just call the constructor to establish inheritance. You could if you hacked all your constructors to know that they were being called for inheritance. That would just be plain ugly

However, there is a solution to this which involves surrogate constructors. This was developed by a co-worker here at our company within a library he wrote called class.js. Basically this is what you would do.

// Function to be used as a surrogate constructor to avoid
// instantiating a parent class just to setup inheritance
function surrogateCtor() {}

// Outputs:
// Being constructor called (just once, awesome)
// Name is Robert
// Breathes:true
// Gets bored: false


This could be abstracted with the following code

Function.prototype.extend = (function() {
function surrogateCtor (){};

// --- Testing code -----
var tri = new Triangle(5);
console.log(tri.getPerimeter());// outputs 15


I would humbly like to ask of you to embrace JavaScript.

Well said…

The three of us whom write javascript has a silent agreement to avoid it, I think. There are times when it is tempting to do it just because you can, but one use to find a more straightforward way to solve the problem during the coffee break.

Thanks for sharing! I was hoping someone would express their love for a class-based approach.

It depends on a few factors, as you say: in very, very large projects it might become useful, but my estimate is, like you say, that memory usage will increase (and while not dramatically, every byte counts for me).

In terms of private and protected properties and methods, the Yahoo Module Pattern offers you just that: one part which can be private and another with protected or public methods.

Regarding your JavaScript framework, if it ever becomes official, please let me know!

However, I feel that in some cases it can be real usefull to mimic class based languages in some respects. Again it’s utterly dependent on user case and personal style, but for larger codebases, I prefer such an approach. However, this has issues as u describe.

What is needed for the class based emulation approach is something that gives us the goodies from other languages, without sacrificing native js syntax and behaviour. I do know a solution, but it’s in-house developed (I own it, but I agreed not to make it public yet). Forgive me to bring it up here, but I need it to illustrate my views.

To cut short, it’s possible to merge the two approaches gracefully. At home I can make class-like structures that I can use the native way, without any further calls to Class.extend() or something similiar. All magic is done by putting a few calls into the constructor and after that u can instantiate the classical way (ie with ‘new’).

Since I constructed this little lib, my productivity has increased dramatically. I now can have private, protected and static methods/properties. I have access control to classes and methods. When debugging I now get meaningfull errors, my objects can be introspected without writing endless for-in loops, etc. The trade-off is an increased memory usage, but that only shows when one creates something silly like 100.000 classes, and even then we’re not talking megabytes here.

While I agree that such things are overkill for ordinary websites, for larger projects I feel classical js falls short. At some point it pays off to start using a framework, if only to make the codebase easier to maintain. The way I use MF – Mystery Framework – I have the best of both worlds. I have all the benefits of js prototypical nature AND the ease of constraints like we know from Java. Lovely when the codebase surpasses the 1000 lines or so.

Forgive me this elaborate post again, but it has been a while and I don’t seem to be able to post anything short anyway

Cheers to all that made it this far!!!

But is that the framework pushing you into using it, or just that it would’ve been needed when you had it, no matter which JavaScript library you were using?

Interesting, thanks for the tip!

Anders,

Glad you liked it! The metaprogramming chapter is my favorite chapter in a JavaScript ever (or at least for a long long time)!

Kudos for using dLite!

By the way, would you say that by using Prototype at work for inheritance, that you might overuse inheritance inadvertedly or not?

Andrea,

Thanks! I haven’t fully read your document, but it looks quite good!

The only thing is: why people completely ignore my document?

Since I’m bound to Prototype in my current project at work, I stick to their class-like inheritence during office-time. On my own though (no libraries here except DLite), I will start to use the module pattern since it make sense to me.

If you’ve missed it (which I’d be surprised) the Open Web Podcast episode 2 has a bit of a discussion of the inheritance issue, which is kind of interesting.

http://openwebpodcast.com/