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

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

On Sep 24, 2007, at 5:37 PM, Geoff Knauth wrote:

> I can't think of a more appropriate list!
>
> strict-import sounds like a reasonable feature.  The only thing I  
> don't like about it is users having to change their imports into  
> strict-imports.  Users might get paranoid that "import" is no  
> longer good enough, so then they'd be typing the longer version all  
> the time.  I wonder if it would be possible to do something like  
> (strict-imports boolean) so that people wouldn't have to change  
> their code, only the current loading behavior.
We could probably just change the implementation of import so that it  
signals an error if the class is not found.
This might temporarily break some old code, but only if it were  
important classes that didn't exist, in which
case the imports could be taken out or enclosed in a trycatch  
expression.

---Tim---

>
> Further comments below.
>
> On Sep 24, 2007, at 16:54, Kyle R. Burton wrote:
>
>> Is jscheme-devel the appropriate list?  I received a message  
>> indicating that the message is awaiting moderator approval.   
>> Should I just be using jscheme-users?
>>
>> Thanks,
>>
>> Kyle
>>
>> ---------- Forwarded message ----------
>> From: Kyle R. Burton <kyl...@gm...>
>> Date: Sep 24, 2007 4:49 PM
>> Subject: feature request: strict-import
>> To: jsc...@li...
>>
>> 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.
>>
>> 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.*")
>>
>> 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.
>
> I like that argument.  I could have used it in previous battles  
> discussions with management in years past.
>
>> 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?
>
> I wonder if anyone is still using JVMs prior to 1.2?  I guess they  
> could still use "old" JScheme.
>
>> 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.
>
> We can run tests!