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.

On Sun, Mar 29, 2009 at 11:56 AM, Per Cederberg <cederb...@gmail.com> wrote:
>
> 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
>
> On Sun, Mar 29, 2009 at 3:26 PM, Freek Zindel <zin...@gmail.com> wrote:
>>
>> 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 mochikit@googlegroups.com
To unsubscribe from this group, send email to 
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to