why use MochiKit.Base.update to create the mochikit object hierarchy?

10 views
Skip to first unread message

Freek Zindel

unread,
Mar 29, 2009, 9:26:54 AM3/29/09
to MochiKit
When looking at the source code for MochiKit I found that the object
hierarchy is created with calls to update. e.g.:
MochiKit.Base.update(MochiKit.Dom,{...});

I am eager to learn about the rationale for doing this so that I may
enhance my understanding of javascript.

What is the advantage of using this technique over an assignment such
as:
MochiKit.Dom = {...}

I am aware of the benefit of having the option to call update several
times, each time adding some extra functionality to an object. But if
only one call to update is made for a specific part of the MochiKit
tree wouldn't the work that update does just be extra overhead?

Or are there other benefits?

Best regards,

Freek Zindel

Per Cederberg

unread,
Mar 29, 2009, 12:56:58 PM3/29/09
to MochiKit
I think Bob is the best person to answer this, but in the current
version of the code "MochiKit.DOM", "MochiKit.Style" and friends are
all created by the MochiKit.Base._module function. This function
automatically inserts a few practical helpers, such as the module
name, __repr__() and toString(). So by using a call to update(), these
generated helper properties are kept intact.

An alternative would of course be to assign each property by itself:

MochiKit.DOM.currentWindow = ...
MochiKit.DOM.currentDocument = ...

But I think people would consider this too verbose. I don't mind
myself though, because I think it would increase the code clarity
somewhat.

Anyway. The "correct" way of doing a library nowadays I think is this:

(function(scope) {
... declare stuff ...
... export selected resources into 'scope.MochiKit.DOM' ...
})(this);

That would hide internal methods securely inside an inner scope. But
sometimes the internal methods are quite handy of course...

Cheers,

/Per

Bob Ippolito

unread,
Mar 29, 2009, 1:37:26 PM3/29/09
to Per Cederberg, MochiKit
The reason I chose not to hide methods in a scope is so that you could
monkeypatch them if you needed to. In retrospect I probably should've
just done it in a scope because it would make the code smaller. Using
an object literal was the compromise I chose between assigning each
property by themselves and using a closure.
Reply all
Reply to author
Forward
0 new messages