[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