help-jel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-jel] Feedback on JEL


From: Johnson, Tony S.
Subject: [Help-jel] Feedback on JEL
Date: Mon, 30 Jul 2001 10:31:32 -0700

Hi Konstantin, I have been exprimenting with using JEL in some scientific data 
analysis software I am developing (http://jas.freehep.org). It works great for 
most of the things I have tried it for so far!

I do have a few suggestions/questions about possible future enhancements:

1) Currently if I want to use a used defined variable I must define a 
DVResolver, and a dynamic library that has methods of the form 
getXXXProperty(String x). This works quite well, but it has the disadvantage 
that I must work with Strings (x) in the getXXXProperty routine at expression 
evaluation time. In my case I want to deal with columns in an NTuple, so I 
would like to be able to translate column names to their row number, e.g. 

       2*x

should be treated as:
 
       2*doubleColumn(1)

Avoiding the need to deal with strings at expression evaluation time would 
speed things up. I wonder if it would be possible to have a more flexible form 
of DVResolver which allows me to translate my user variables to an arbitrary 
expression, thus I could have

       DVResolver.substitute(x) --> doubleColumn(1)

You current implementation would then become a special case of this more 
general substitution.

2) Currently CompiledExpression.getType() returns an int. I wonder if you have 
considered instead returning a Class. There are already Classes defined for all 
the Java primitives, so you could return Double.TYPE, Integer.TYPE etc for your 
current case. This would have the advantage that in the case where the 
expression returns an Object I could find out what type of Object will be 
returned, which I cannot currently do. For example if expression is:

             "ABC"+"DEF"

getType() would return String.class

3) Finally a small point. You implementation uses a custom ClassLoader. If my 
application already has its own class loader it would be nice to specify that 
the ClassLoader created by JEL should use my own class loader as its parent. 
Unfortunately ClassLoader parents were only introduced in JDK 1.2, so you 
probably cannot support this and maintain full JDK 1.1 compatibility. 

Once again thanks for creating the expression evaluator, and I hope these 
suggestiosn are useful. Let me know whether you think they make sense.

Tony Johnson





reply via email to

[Prev in Thread] Current Thread [Next in Thread]