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

[Matthew Eernisse]

Cosmo list folks,

Nicola, thanks very much for your message, and for your example of the 
problem you're having. It makes it very clear what you're talking about now.

Nicola Piccinini wrote:
> Hi Matthew,
> 
> I'm sorry you are wasting time with me.
> By now it's evident that I'm not able to express my ideas in English :-(

It was absolutely not a waste of time -- your messages to the list 
touched on some issues that have come up a number of times in 
discussions with the other developers, but we have never directly 
addressed or clearly settled. They both have added replies to your 
message, and I'll just respond to everything all together here.

(By the way, I speak Japanese as a second language, and I know how hard 
it can be to express your ideas and to be sure that other people are 
understanding your intended meaning.)

This is what Travis had to say:

> 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.

I agree 100% that separating namespace objects from business objects is 
a good idea, and hiding the creation of the object off in the Dojo 
packaging system might encourage that. However in some cases it seems a 
little gratuitous -- for example, do we want to have a cosmo.app.pim.Pim 
object that only has an init method and basically nothing else in it?

I'd also point out that doing things the common.js way gives with one 
hand, and takes away with the other -- it may encourage better 
namespacing practices but it breaks encapsulation/information-hiding by 
taking away real private variables and methods. Although I know that 
Travis has no issue with that, and Bobby actively prefers it.

Here's what Bobby said:

> I know mde is not a fan of these pseudo private variables, but the
> fact is that having all these long lived variables hidden in closures
> makes it extremely difficult to debug. I like being able to probe the
> value of a variable by popping open the javascript shell. With these
> closures you cannot do that, you have to add code (debug statements
> or something)
> 
> I've been running into this a lot in the Cal and Canvas code and it's
> been slowing me down quite a bit.

Yes, the use of underscore with public properties as a flag for "this is 
private" seems to me to be kind of cheesy when JavaScript has actual 
private variables and methods available. But I can also see the value of 
being able to explore them in Firebug or some other shell without having 
to add debug code.

It affects the other team members more than it does me, since the 
affected code they're working in is mine, and I know mostly where stuff 
is anyway. If it'll make things easier for them, I'll work to overcome 
my knee-jerk sense of revulsion and work with the underscores. :)

Sounds like a clear consensus for letting the Dojo packaging system 
create the namespace objects, and not using local scope for private 
variables or functions. Unless someone else has an objection, I'll 
consider that our standard approach, and as opportunity presents itself 
I'll migrate the two problem places in the code over to use a common.js. 
file and underscored public members instead of private ones.

The cosmo.app.pim namespace conversion will be fairly easy, since 
there's less code -- and the other offender, cosmo.view.cal.canvas, is 
in need of some serious work anyway to remedy all the ugly shim code 
sitting in there that bridges the render method of the 
cosmo.view.cal.canvas.Canvas object with the rendering code sitting in 
cosmo.view.cal.canvas.

Note: I will not be doing this conversion any time in the immediate 
future, as it would have negative impact on scheduling. (Just added that 
to make sure Ted isn't hyperventilating. :))

Nicola, thanks very much for getting this discussion started.


Matthew