why no namespacing?

[no-zzz-un]

why isn't tslib/ code namespaced under Turbulenz module or something?

i.e., during development i ran into a global name collision with 'debug' from jslib/debug.js, and 'Utilities' from jslib/Utilities.js

i see that makehtml removes these global variables (i'm not sure how though), but this is still a problem during development

not having it's own namespace moves Turbulenz slightly closer to being a framework than a modular library

[ianballantyne]

It's something we've discussed doing, but requires a bit of large restructure for some of our processes. If this is something that is other developers feel is important to them, we'll see if we can propose a solution. Let us know in this issue.

[patrickd-]

+1 from me

This structure is also a real pain when I just need specific features but the libraries access global variables such as "TurbuenzEngine" within the global namespace without checking if it's even there.

I'd prefer if the Engine does not make any assumptions about the global namespace and if it needs something it should need it by constructor dependency injection. This is especially important for using WebWorkers as there is eg. no "window" global context.

Also, I'm no js expert but I can't see much advantage in the static .create() methods you are using to instantiate your classes. These are quite annoying as they cannot be inherited properly (due to the static dependency on the class itself) which makes extending them very ugly.

[davidgaleano]

The static .create() methods are a bit of legacy from the past, from the days when we started using JavaScript, it was one way to make sure we never called the constructor without the "new". More and more we are moving the code from the "create" to the constructor, using static analysis tools for avoiding writing silly mistakes.

[patrickd-]

Ah! Thanks for the info.

If you need more human resources for re-factoring such parts of your codebase let me know, I'd be glad to help making this project more widely usable.

[davidgaleano]

I would propose using the Turbulenz Engine user forum to organize development of this kind.

[ghost]

I'm a big fan of Douglas Crockfords' work - I think he has the right ideas about how Javascript should be written. Having said that, I think the OP has a solid, rational point. Polluting the global namespace is one of worst sins we can commit for the very reasons mentioned. The structure of Javascript requires that we put such commonly named items into private namespaces to prevent this very occurrence. And looking at the code base it's entirely plausible.

It's not a trivial effort, but it's also not a complete rewrite and I think a group of focused folks could get it done over a couple of months, maybe faster. I'm down.