[e-lang] Joe-E Library

Adrian Mettler amettler at cs.berkeley.edu
Fri May 18 00:30:59 EDT 2007


I've been working on the library the last few days; I have some 
questions (this is based on the version of the Joe-E library available 
as part of the ref_send 0.22 from sourceforge; 0.23 is identical) for 
those who want to follow along.  I'd be interested in comments on the 
following issues.

org.joe_e.struct:
Does it make sense to make this implement "Serializable", so people 
won't have to manually add "implements Serializable" to types that 
extend Struct?  It seems to go with Struct's aim of simplifying things, 
but they will still have to define a serialVersionUID.  Do you forsee 
anyone wanting to have a non-serializable Struct?

org.joe_e.file.Filesystem:
The ref_send version has a special case for the empty path that allowed 
it to work like "." when used with name() (as opposed to acting like the 
root directory in that circumstance). list() is broken for it though, as 
Java's listFiles() doesnt' work with the empty file (at least not on Linux).
new File("").getAbsolutePath() gives the current home directory
but new File("").listFiles() returns null.
For this reason, I'm not sure if it's worth making "" work with name(); 
in my current version, I just throw an IllegalArgumentException if the 
first argument to name() is null or represents the empty path.  Please 
let me know if this sounds like a problem.

org.joe_e.reflection:
At the moment, Reflection performs checks to ensure that all members 
returned are public (this is the only way to get 
Field/Method/Constructor objects in Joe-E), and Deflection (the only way 
to use such objects) ensures that the members belong to public 
classes/interfaces when they are used.  Is there a reason that these 
checks are separated?  Would it make more sense to check both for the 
publicness of the member and the class that defines it initially, 
instead of splitting the checks into two pieces?  Is it necessary for 
some reason to be able to create (but not use) public members of 
non-public interfaces?

Oh, and I made with() work; the backing store is Object[] now. (It was 
broken before in some edge cases when you passed in an array to the 
factory method rather than using varargs). *gripes about covariant arrays*

-Adrian



More information about the e-lang mailing list