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

[Freek Zindel]

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg]

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

Post by Freek Zindel
When looking at the source code for MochiKit I found that the object
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
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Bob Ippolito]

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.

Post by Per Cederberg
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.
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.
(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

Post by Freek Zindel
When looking at the source code for MochiKit I found that the object
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
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---