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 mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg-2]

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 <zindel@...> 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@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
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.

On Sun, Mar 29, 2009 at 11:56 AM, Per Cederberg <cederberg@...> 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 <zindel@...> 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@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---