[Cosmo-dev] Re: [commits-cosmo] (br) [4567] this is a better way not to clobber namespaces.

[Matthew Eernisse]

Nicola,

Thanks for your message. Please find responses/comments inline, below.

Nicola Piccinini wrote:
cosmo.view.cal is a namespace.
> Moreover cosmo.view.cal is also a singleton, in fact in cal.js we have:
> cosmo.view.cal = new function () {
> ...
> }
> 
> That means that Lozenge, canvas, etc. are properties of this singleton 
> and if the singleton is inadvertely reinitialized, this properties are 
> lost. This in fact caused me some troubles and I had to "mixed in" the 
> cosmo.view.cal object with cosmo.view.cal namespace to solve them.

If I read what you're saying your problem is correctly (and maybe I 
don't), it seems like you might be misunderstanding the model for 
JavaScript namespacing.

In JavaScript, all namespacing is done with objects -- so anytime you 
have some namespace of something like foo.bar.baz, that means that each 
of those links in the namespace chain is simply a plain JavaScript 
Object object stuck on the parent as a property.

Since there's only one of each of those objects, each branch of that 
namespace hierarchy would technically be referred to as a JavaScript 
singleton object.

Bottom line is that all namespaces in JavaScript are objects. Here are 
some links with some more details on the JS object model:

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Working_with_Objects
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Details_of_the_Object_Model
http://javascript.crockford.com/prototypal.html
http://javascript.crockford.com/inheritance.html
http://javascript.crockford.com/private.html

If I'm telling you stuff you already know, and I'm just misunderstanding 
your issue, I apologize.

> As far as I can understand, in cosmo 0.7 things aren't much different in 
> fact in [4567] you are mixing in the "new function()" with the 
> namespace. The situation is even more awkward because of the scoping 
> questions explained by Travis.
> 
> So my point is: why not to avoid some of these potential problems 
> separating cosmo.view.cal namespace from cosmo.view.cal object (which 
> could become cosmo.view.cal.Cal)? What are the advantages in maintaining 
> the current double nature of cosmo.view.cal?

There is no double nature, except what you have inherently because 
you're using JavaScript -- namespaces *are* in fact objects.

The cosmo.view.cal object is a JS singleton object used only for 
namespacing in our code. It has no other purpose.

You might be a little confused because Dojo's 'require/provide' stuff 
"magically" creates that object (likely either using the throwaway 
constructor "new function" or with a object literal, "{}"), and you can 
see in my code where I'm creating the object myself.

The reason I've been doing things this way is because I want to take 
advantage of the normal stuff you expect to have within a particular 
namespace in JavaScript -- specifically the shared scope that allows you 
have have private methods, or private variables that are visible to all 
the public methods of the namespace:

var foo = new function () {
     var doPrivateStuff = function (s) {
         alert('private stuff from ' + s);
     }
     var bar = 'bar';
     this.baz = function () {
         alert(bar);
         doPrivateStuff('baz');
     };
     this.fizzy = function () {
         alert(bar);
         doPrivateStuff('fizzy');
     };
};

It may be the case that this becomes so much of a hassle that it's not a 
tenable approach, but so far Travis's creative use of dojo.lang.mixin 
means that we can use the packaging system without throwing out the 
ability to do things the JavaScripty way.

Hope that clarifies things a bit for you. If I'm totally 
misunderstanding your question, again, apologies.


Matthew