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

[Travis Vachon]

Hi Nicola

Thanks for starting this conversation. At some point we should really  
have a more in depth decision making session about how we want to use  
the Dojo namespace/module system. We're in the interesting position  
of being some of the first people to do a project on this scale using  
Dojo as a base and we're seeing the pain of working without a  
canonical set of best practices.

That said, I think you're correct, and I think this is why Dojo is  
moving toward dojo/foo/common.js. In doing this, they are encouraging  
a practice that stricter languages like Java enforce: separation of  
namespace and business objects.

Just because we can treat namespace objects as regular objects  
doesn't mean that we should, and I would very much like to have a  
conversation and decision on best practices moving forward _very_  
early in the 0.8 release!

-Travis

On Jun 6, 2007, at 10:56 PM, Nicola Piccinini wrote:

> Hi,
>
> thanks for your kind reply.
> Unfortunately my message was vague and I need to make it more precise.
>
>> Actually, in the 0.6.1, the references to 'Cal' you see in the  
>> code point to cosmo.ui.cal_main.Cal. You can see the alias at the  
>> bottom of cosmo/ui/cal_main.js.
>
> yes but I meant really cosmo.view.cal (sorry for confusing ideas  
> calling it "cal" singleton).
> In Cosmo 0.6.1 we have the following hierarchy:
> cosmo.view.cal
> cosmo.view.cal.Lozenge
> cosmo.view.cal.canvas
> cosmo.view.cal.conflict
> cosmo.view.cal.dialog
>
> So 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.
>
> 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?
>
> Many thanks,
> Nicola
>
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev