Re: [Jscheme-devel] feature request: strict-import

[Timothy J H. <tjh...@br...>]

On Sep 24, 2007, at 4:49 PM, Kyle R. Burton wrote:

> The current import function is lazy, which nice from an interactive  
> point of view.  From knowing that the code will execute point of  
> view, it is less desirable.  I'd like to propose an additional  
> function: strict-import that would error if the class being  
> imported is not actually found at the time the strict-import is  
> processed.
That sounds reasonable and not too hard to implement.
>
>
> I can think of a few ways that strict-import could behave:
>
>   (strict-import class-name)
>
> In addition to calling Import.addImport, this would also validate  
> that the class can actually be loaded, otherwise it would throw an  
> exception (class not found exception).
>
>   (strict-import "class.or.package.name.*")
>
> If the arg prefix (dropping the wildcard) is a package name, then  
> this works exactly as the existing import (no detectable errors).   
> if the arg prefix is a class name, then all the static methods in  
> the class are imported as symbols in the current environment:
>
>   (strict-import "java.lang.Math.*")
This is something we would need to discuss.
The nice thing about the javadot notation is that you can tell by  
looking at a procedure name if it is a Java element
and if one follows the convention of not using "." in any user- 
defined scheme names, then it separates those name
spaces syntactically.

If we break that naming convention one could import a Java class that  
contains a static method "car" which could
reek havoc with any scheme code ...

Another approach would be to specify which static methods should be  
imported without the "." notation, e.g.
      (string-import "java.lang.Math" '(random ulp IEEEremainder))

>
>
> Would create a function 'random in the current environment.
>
>   (strict-import "java.lang.Math.random")
>
> In this case the form is requesting the importing of a single  
> static method from the Math class, it would create a function  
> 'random in the current environment.
>
>
> I can work at creating an example implementation some night this  
> week (I don't expect it to be difficult) if it is warranted.
>
> We're using JScheme in one of our production applications (for a  
> DSL) and we're looking to have it be as strict as possible so that  
> we end up deferring as few errors/issues to runtime as possible.   
> Detecting failed class imports (when the class is not actually on  
> the classpath) would help towards this goal.
Adding some error checking sounds like a good idea to me..
>
>
>
> Also, I've noticed that the implementation uses Vector and  
> Hashtable quite a bit.  I realize that they were what was available  
> when JScheme was created and the newer (and generally considered  
> better) ArrayList and HashMap were not available until java 1.2.   
> Is there any reason at this point not to switch the code to use the  
> newer collections framework?  There may be a performance difference  
> since ArrayList and HashMap are not synchronized themselves - and  
> it looks like the code in JScheme is doing a lot of the  
> synchronization itself anyway.
This is a very interesting idea.
A more ambitious project would be to rewrite the JScheme codebase  
using the newer collections and generics.
If there is enough interest we could start work on this and take the  
opportunity to clean up the code and javadoc
comments throughout....

Best,
---Tim---