Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ease-dev] loadModule() and namespace pollution
+1

In Python land this will be very welcome! It will also make it possible to better integrate other tools such as the PyDev editor because symbols are no longer created "magically". 

As for the environment module staying in the global namespace I say 0. In _javascript_ it is pretty standard to have things added to the global namespace, but not so in Python scripts*. I would be very happy to see something like "import ease" pulling in the environment module. This should be doable with import hooking[1]. I think the same should be done with top level java packages (com, sun, java, javax, etc). 

* Python interactive consoles do expect to have extra things added.

[1] http://blog.dowski.com/2008/07/31/customizing-the-python-import-system/

Jonah

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

On 21 June 2017 at 12:49, Christian Pontesegger <christian.pontesegger@xxxxxx> wrote:
Hi script developers,

recently Martin and I were discussing how modules bind their functionality into the script engine. While putting everything to the global namespace seems convenient for simple scripts and users not so experienced with OO patterns, it might lead to troubles when lots of modules get loaded, possibly using very generic function names (eg clear, reset, init, ...). It not only fills up the global namespace, it also might lead to errors when existing functions get overwritten by a module load or vice versa.

So I opened bug 518567 [1] to track this topic and came up with a first approach how to handle this issue [2].

The implementation adds a new optional parameter to loadModule, that allows to bind its functionality to the global namespace or a returned variable.

// old way, everything goes to the global namespace
loadModule("/System/Resources"); // still works, same behavior as before
loadModule("/System/Resources", false); // optional parameter to not use a custom namespace
getWorkspace();


// new implementation, does not store to the global namespace
res = loadModule("/System/Resources", true); // dynamic JS object is created, nothing gets stored to the global namespace
res.getWorkspace();


The patch is currently only provided for _javascript_ and is meant as a basis for discussion. The benefit of the implementation is that all scripts available so far remain valid and do not need any update.
If users do want to keep their namespace cleaner, they can opt in to do so.

One topic remains: the Environment module still gets loaded to the global namespace. Probably this is fine for everybody, if not we need to think further here how to remain compatible with the existing infrastructure.

Please let me know what you think of it,

Christian

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=518567
[2] https://git.eclipse.org/r/#/c/99741/

_______________________________________________
ease-dev mailing list
ease-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ease-dev

Back to the top