[e-lang] Joe-E Library

[Adrian Mettler]

Tyler Close wrote:
> 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.
> 
That's good enough for me; it'll stay as is.

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

For ref_send, the Reflection methods aren't used, so it doesn't matter 
if we're worrying only about it.  The restrictions on interfaces 
implementable by Joe-E proxies look to ensure that the members visible 
to invocation handlers are always members of public interfaces (and thus 
public); using only the Deflection interface the only members one can 
get ahold of look to be completely public.

If I remember correctly, the Reflection API was provided not for use by 
ref_send, but for another project being worked on (and by web_send?). 
How does it make use of the reflection API?

It seems that it would be clean to prevent exposure of reflected objects 
that can't be used.  The most natural (and substantially more convenient 
for users) way to do this would be to perform the bubble() logic in the 
library, but that's expensive and not always what one wants...  perhaps 
the best way would be to have a brain-dead version that omits them, and 
another one that does the bubbling?  But then there is the issue of 
whether to bother bubbling statics.  Use cases might be helpful here, to 
see if there are only a few possibilities worth implementing and thus 
doable within the library.

If this isn't the case, and there are a number of behaviors clients 
would want, the current approach, ugly as it is, is probably as good as 
its going to get, unfortunately.  I'll think about it some more.  Any 
other ideas?
-Adrian