couldn't the "@ = require" construct still have conflicts?

Skip to first unread message

Darren Cruse

Nov 11, 2015, 10:39:58 AM11/11/15
to StratifiedJS
Was going thru the chat tutorial so another newbie question that I was just real curious about.

I follow that the "@" becomes a namespace that nicely avoids conflicts with locally declared variables.

But considering e.g. (from near the end of the chat tutorial):

= require(['mho:surface', 'mho:rpc/bridge', 'sjs:event']);

Am I wrong that since this is putting *all* the exported functions of "surface", "bridge", and "event" on the "@", there could in theory be overlaps in the names from the different modules that would conflict?

(i.e. not worrying about these specific modules but considering some hypothetical example with some arbitrary combination of other modules) 

I was just wondering if I was right to the think that (at first I thought it was saying the "@" approach *ensured* no conflicts - but that's only between the imports and the locals right not between the various imports exposed on the "@" right).

No biggie just curious,


Alexander Fritze

Nov 11, 2015, 1:25:50 PM11/11/15
Hi Darren,

The require(.) call ensures that there are no clashes between the
modules it loads in. If there are, then an error will be thrown.
So if you have a module 'a.sjs' with an export 'foo', and a module
'b.sjs' also with an exported 'foo', then calling "require(['a',
'b'])" will give an error.

'@' itself doesn't care about what you set on it. If you do '@foo = 1'
and later '@foo = 2', then '@foo' will just be overwritten.
'@' is really just a module-local object that gets initialized to {}
at the beginning of a module, and that allows access to its members
without a '.'. Internally, SJS translates the code:

@ = require('a');


var __alt_namespace = {};
__alt_namespace = require('a');

> --
> You received this message because you are subscribed to the Google Groups
> "StratifiedJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
> For more options, visit

Alexander Fritze
Reply all
Reply to author
0 new messages