Re: [ease-dev] Could EASE helper modules have only a static public inter

[Christian Pontesegger <christian.pontesegger@xxxxxx>]

On 29.11.2014 17:35, Paul D. Fernhout wrote:
> Is trying to resolve this worth the trouble or the extra complexity 
> (including for cleanup of ThreadLocal variables to prevent leaks) 
> compared to just making module instances that know what interpreter 
> they go with? I don't know because I still don't know for sure if it 
> is possible or how complex and brittle the EASE code would become as 
> far as maintenance with such a change. However, I suspect though that 
> this may not be that hard to do, perhaps with some function like 
> getCurrentEaseContext() that would get the ThreadLocal context. If it 
> was easy, then perhaps the whole process of writing and importing core 
> EASE modules could be simplified down to importing Java classes with 
> only static methods.

Having static modules would mean to keep them stateless. Thus any engine 
specific values would have to be stored in the engine context.
Currently all script engine implementations inherit from 
core.runtime.jobs.Job. So you could detect the running engine by using 
something like Job.getJobManager().currentJob(). There is one exception 
to this rule: executeUI() which executes code outside of the engine job. 
In such cases there exists no way to detect the running engine.

Personally I see quite some effort in moving module specific stuff into 
a global context. It would also break OO design principles like 
visibility (as private module fields become part of the public context 
of the engine). Most of it all I do not see the big benefit of having 
static methods. As stated in 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=453225#c3 problems arise 
by mixing Java and script language styles. These are 2 different ways of 
coding which should be mixed with care.

--
Christian