[ease-dev] Could EASE helper modules have only a static public interface

["Paul D. Fernhout" <pdfernhout@xxxxxxxxxxxxxxxxxx>]

This is a spinoff of Bug 452689. I feel it would probably be easier to 
directly use UIModule and similar modules that supply Eclipse helper 
services (like setting the clipboard or putting up a warning dialog) if 
they had static public methods instead of instance methods requiring 
creating (or finding) an instance first. This approach is instead of 
using "loadModule" to define global methods, which obviously is another 
way to get access to this functionality. Is there any reason that an 
EASE user would need to make an instance of such modules first in order 
to use them directly through language-specific class loading 
functionality like "import" or whatever?

Here is an example interaction with the Rhino Script Shell.

> org.eclipse.ease.modules.platform.UIModule.setClipboard("hello");

	Java class "org.eclipse.ease.modules.platform.UIModule" has no public 
instance field or method named "setClipboard".

> org.eclipse.ease.modules.platform.UIModule().setClipboard("hello");

	[null]

Note the extra "()" to create an instance in the second try. After that 
second try, I can now paste "hello" into an Eclipse window from the 
clipboard. But I don't know what the implications are of having made an 
instance of the UIModule, like whether it allocates resources it needs 
to clean up, or something like that.

For anyone who wants to use these helper modules directly from a script, 
bypassing loadModule, I guess it comes down to whether one is OK with:

  var UI = org.eclipse.ease.modules.platform.UIModule();

as opposed to:

   var UI = org.eclipse.ease.modules.platform.UIModule;

Before doing:

  UI.setClipboard("Hello");

I think the second form is clearer for someone who understands Java, 
because it implies there are no unexpected side effects within EASE to 
accessing the helper function other than what the function does to 
Eclipse itself. There may still be side effects from calling a class 
method of course, but it breaks an implicit expectation about such things.

Any comments on why the public interface of an EASE helper module can't 
be (mostly) static methods? It seems to me that this approach should 
work with all supported languages? Could any unusual cases requiring 
some sort of initialization be moved to their own module? Or perhaps for 
modules defined by loadModule, even if you need an instance of something 
to represent the module, perhaps the instance side could just call 
static versions of these methods?

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies 
of abundance in the hands of those still thinking in terms of scarcity.