Tuesday, February 24th, 2009

Creating another library called Prototype?

Category: JavaScript, Library

Ben Gerrissen has created a library to handle prototype-based inheritance and the module pattern.

The problem is that Ben named it Prototype! Are you kidding me Ben? :)

As a reaction to the Javascript Inheritance Performance post, I found myself thinking; “Why is everyone trying to superimpose Classical OO on Prototypical OO” and “There should be a better way according to what Douglas Crockford tries to teach us through his articles and book”. So I got to work and Prototype + Prototype.Module is my idea on how to handle inheritance in a nice and orderly way.

Other inheritance systems solve it function.prototype = {} >here<. This inheritance system solves it >here< function.prototype = {}

Prototype Example

The Prototype function basically leaves the functions alone and only handles property hashes, so we can assign them to functions AFTER they’re properly defined. It also supports multiple inheritance the prototypical way and allows back references to donor property hashes.


  1. Prototype("MammaCat", {
  2.         talk: function() {
  3.             return this.name + " says: miauw";
  4.         }
  5.     });
  7.     var MammaCat = function(name) {
  8.         this.name = name;
  9.     }
  10.     MammaCat.prototype = Prototype("MammaCat");
  12.     var Pookie = new MammaCat("Pookie");
  13.     alert(Pookie.talk()) //==> Pookie says: miauw


Prototype.Module provides a neat way to organise Module Patterns as well as allow the sharing of private variables over multiple Module Patterns through closure techniques.


  1. Prototype.Module("combat", function(cache) {
  2.         cache.baseDamage = 10;
  3.         return {
  4.             rake: function() {
  5.                 alert(this.name + " rakes for " + cache.baseDamage + " damage");
  6.             }
  7.         }
  8.     });
  10.     Prototype.Module("specialAttacks", function(cache) {
  11.         return {
  12.             claw: function() {
  13.                 // yes, we reference a value set in another module pattern through the cache argument!
  14.                 alert(this.name + " claws" + (cache.baseDamage + 10) + " damage");
  15.             }
  16.         }
  17.     });
  19.     // the cache argument in the module patterns gets shared as long as you assign the
  20.     // modules in a single call.
  21.     Prototype.Module.attach(Pookie, "combat", "specialAttacks");
  22.     Pookie.rake(); //==> Pookie rakes for 10 damage
  23.     Pookie.claw(); //==> Pookie claws for 20 damage

Interesting stuff Ben, but please change the name :)

Posted by Dion Almaer at 5:27 am

3 rating from 19 votes


Comments feed TrackBack URI

Douglas Crockford tried to teach us how to extend objects via prototype chain, which is the technique used by 99% of libraries to extends “classes”.
I do not get the purpose of above post (and the library name as well).

Comment by WebReflection — February 24, 2009

@Dion, thanks for posting =) Yes I should change the name, but Proto is taken and Blueprint is taken as well and I like a good name that describes the function.

@webreflection, most Class decorators return a function (class) and the messes around with inheritance referencing directly to the function’s prototype attribute. This library takes functions out of the equation and deals in property hashes. The hashes are portable and mixable, and you can assign the result to a function’s prototype. It’s a subtle difference but more prototypical (imo at least) approach. Most Class methods really steer away from Douglas Crockford’s Object.beget method and this goes back to the foundation. Don’t manage function prototypes, but manage the property hashes.

Comment by BenGerrissen — February 24, 2009

ehr … Ben, I am sorry to inform you that prototypes are Objects :D
I think most library have no confusion at all about JS inheritance and mainly because they “brings and/or modify” hashes around via Crockford suggestion (which is not perfect, because you do not need to create a new function for each clone)
if (typeof Object.create !== 'function')
Object.create = (function(F){
return function(o){
F.prototype = o;
return new F;

Comment by WebReflection — February 24, 2009

P.S. about the “inform you” I was joking while about Crockford way it is perfect to extend prototypes because of the empty constructor. So you can always call new F() without executing the one which defines the prototype you would like to inherit ;-)

Comment by WebReflection — February 24, 2009

I hear he’s also working on a project to better lazy load scripts called Scriptaculous.

Comment by igaenssley — February 24, 2009

returning closure? doesnt that mean that for every object created as an instance of Pookie – every method is defined as a different instance? Does that mean if I create 1000 object of Pookie in memory we get 1000 of methods rake() ??

From what i know the biggest advantage of simple .prototype is that if I do:

var Pookie = function()
Pookie.prototype.rake = function() { alert(‘do rake’);}

When I create 1000 object of Pookie I still use only one function rake.

Correct me if I’m wrong please

Comment by wilq32 — February 24, 2009

wilq, you are right ;-)

Comment by WebReflection — February 24, 2009

@wilq & Webreflection, thats not the case… The same thing happens as if you where to assign a prototype like so:

myClass.prototype = {method:function(){}}

The main difference and added functionality, is a means to manage and mix what comes after the = in the above example. The prototype assignment is a direct reference to the stored property hash.

myClass.prototype = Prototype(“properties”);
myOtherClass.prototype = Prototype(“properties”);

The prototypes of the above classes are the same object… Any changes made to the stored property hash, will also be implemented on the prototypes of myClass and myOther class.

I guess I have to blame myself for not writing this more cleary, then again, I wrote too much in one sitting.

Comment by BenGerrissen — February 24, 2009

Please rename this to “jQuery.”

Comment by Nosredna — February 24, 2009

For the module pattern however, what you point out IS the case. It will also BE the case in any other way of doing that, wether you define private vars in a Module Pattern or use my Module decorator, my Module decorator however allows the privates to be shared across several Module patterns.

And the thing about private variables, is that you dont want to share private vars with other instances by any other means then getters and setters. If you need to use global variables, then you shouldn’t use the Module Pattern, this is common sense… isn’t it?

Comment by BenGerrissen — February 24, 2009

Relax, in a few years all these libraries will have been superseded. And then there will be all those people who can only use Prototype (the first) realizing they aren’t actually javascript programmers. Y’all might want to take his advice and stop slavishly following a coding style that makes you a commodity… susceptible to obsolescence.

Prototype is dead. Long live Prototype!

Comment by nataxia — February 24, 2009

If the guy didn’t name it Prototype would it be on Ajaxian? Probably not.

Comment by Jadet — February 24, 2009

My “wilq, you are right” was about the question: if I assign a function to a proto every instance shares that function instead of create a new one (like privileged methods).

Ben, private variables in JS inheritance are always shared unless you are not defining them outside a privileged method.

// anonymous instance with private vars
MyClass.prototype = new function(){
var _sharedPrivate = 123;

// note: this is NOT a privileged method
this.getPrivateValue = function(){
return _sharedPrivate;

new MyClass().getPrivateValue() === 123

Comment by WebReflection — February 24, 2009

@Webreflection, it would be nicer for you to base arguments on having actually taken a look at the library. I see assumptions and problematics described this library actually solves… Go ahead, play around with it ;)

As for private variables, I am not arguing nor adressing the examples you put forth. Take a good look at my Module Decorator pattern, the only thing I do here is allow for multiple Module Patterns (as described by the Yahoo Blog post) to share private variables, which was my personal beef with Module Patterns and using module pattern to augment objects.

Comment by BenGerrissen — February 24, 2009

Ben, I quickly read the source, the usage, and thought about your post.
As long as we use functions as “classes”, whatever strategy will end up into a prototype so I cannot spot “differences” but only different patterns around, and to obtain the same result (create an instance inheriting its constructor prototype).
More we “over-mess” this process, less control and performances we have. You are talking about “those guys in Yahoo” which as far as I know are using the bedgeObject concept to extends constructors, and the same is for every common library we create/use.

As summary, you are criticizing developers to use a strategy which your Big Doug Teacher is using as well to extend constructors in the YUI Library so, maybe I should read better your Prototype, but I think you should have a deeper look into other libraries implementations, YUI included.

Comment by WebReflection — February 24, 2009

What about calling it JSoo (or JSOO)… pronounce it “J-sue”.

Comment by shadedecho — February 24, 2009

@shadedecho, JSoo is very nice actually ^^, did a google on it and JS OO pops up all over the place but no lib named that way yet (though I couldn’t read the italian hits I got…)

Mumbo suggested P-Type on over on my blog, but sounds a bit like an Idea I had myself: POO (Prototypical OO), though funny, it obviously doesn’t sound like I respect all the hours I waste in my free time on JS…

Yes, I think JSoo will do nicely, thanks Shadedecho =)

@webreflection, if anything, you showed me I simply did not convey the purpose and intent of my library correctly, I will make a follow up post ;)

Comment by BenGerrissen — February 24, 2009

@webreflection, oh and I have nothing but respect for the guys who come up with inheritance solutions, it’s definatly not my intent to critisize them or to be condensending on their hard work. I will look over the sentence that might even remotely suggest that and edit it, I’m a coder, not a writer…

Comment by BenGerrissen — February 24, 2009

Ben it is about this post introduction: “Why is everyone trying to superimpose Classical OO on Prototypical OO”

Everyone is trying to use what you already know to make things more simple, trying to obtain best performances, and trying to support multiple inheritance when necessary (something YUI ad example does simpler and better than others, my “few days ago” proposal as well)


Comment by WebReflection — February 24, 2009

P.S. my “few days ago” proposal as well means that YUI does better than my proposal as well (I am a coder, not a writer, as you are :D)

Comment by WebReflection — February 24, 2009

Update post: http://www.netben.nl/2009/02/24/67/

Comment by BenGerrissen — February 24, 2009

Ah man is somebody polluting the global name space? wonder who gave ’em that idea.

Comment by mojave — February 24, 2009

I like the way multiple inheritence works and you explicitly pick which ancestor methods to call. (in the updated post)

I don’t get the whole argument above, but this sort of thing looks vaguely cool.

Comment by Deadmeat — February 24, 2009

The original should have never been named Prototype either. It’s inherently lazy to name your library after a feature of a language.

Comment by GregoryD — February 25, 2009

The Object.beget function will be standard equipment in the next edition of ECMAScript, except that it will be called Object.create.

Comment by crock — February 25, 2009

Leave a comment

You must be logged in to post a comment.