[e-lang] Joe-E Library

[Tyler Close]

On 5/17/07, Adrian Mettler <amettler at cs.berkeley.edu> wrote:
> I've been working on the library the last few days

:-)

> 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?

I suspect there will be use-cases for Joe-E in non-persistent
applications. For these cases, it's annoying to have to litter your
code with serialVersionUIDs, just to quiet your IDE's nagging
warnings.

It's also very important that a Serializable class have a stable name,
rather than one generated by the compiler. Serialization will break if
a later compile chooses a different name for the class. By not marking
Struct as Serializable, I think we greatly reduce the chances of
someone falling into this trap, since the syntax for constructing an
anonymous inner class does not allow you to specify both a parent type
and an additional implemented interface. To get both your parent
interface and the Serializable marker interface, you need to make a
named inner class. So by forcing the programmer to use the named inner
class syntax, we make their serialization more robust to change.

I have a strong preference for leaving Struct as not default Serializable.

> 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.

Sounds good.

> 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?

A public method in a non-public class can override a public method in
a public class. java.lang.Class.getMethods() will return the override,
rather than the overridden method. In my original proposal for
Deflection, I handled this issue by finding the overridden method and
returning that instead of the overriding method. The complexity of
this seemed to give everyone (other than me) the wiggins, so we agreed
to just return the override. We need to return the override, so that
the client at least knows the method exists, though it's up to the
client to find the overriding method itself. The override needs to be
present in the returned method list so that the client knows to do
this search.

Simply filtering out the methods declared by non-public classes will
cause me great difficulties. Please don't do that.

> 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*

Oh, let's not get started on Java's type system. ;)

Tyler

-- 
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/