[e-lang] Joe-E reflection API questions

[Tyler Close]

On 4/21/07, David Wagner <daw at cs.berkeley.edu> wrote:
> Comment: fields() returns all fields, including inherited fields.
> field() ignores inherited fields.  That's non-uniform and inconsistent,
> which is surprising and confusing.  I think that either they both should
> return inherited fields, or neither.  I prefer the former.

I'm just going to state the argument for why I made the API the way I
did and why I don't think it is either non-uniform or inconsistent.

The singular version of each reflection method gets access to a fully
specified member and throws an exception if the member does not exist.
The plural version gets a list of all the members.

For the case of fields, consider the following:

class A {
    public final int foo = 1;
}

class B extends A {
    public final int foo = 2;
}

A.foo and B.foo are distinct members with possibly distinct meanings.
Each of these fields can be reflected using:

import static org.joe_e.reflection.*;

final Field aFoo = field(instance, A.class, "foo");
final Field bFoo = field(instance, B.class, "foo");
final A a = new A();
final B b = new B();
aFoo.get(b);   // returns 1
aFoo.get(a);   // returns 1
bFoo.get(b);   // returns 2
bFoo.get(a);   // throws an exception

Now if we delete the B.foo field, the first call will fetch the same
field as before and the second will throw an exception, since the
field no longer exists. To me, it seems inconsistent to have the
second statement return the same value as the first in this case. The
statement asked for the "foo" declared by B, not by A. For example,
the holder of "bFoo" may be relying on it to ensure that a passed
argument is an instance of B, causing the noted exception if it is
not. If we return A.foo when the client asked for B.foo, this check
does not happen and the noted exception is not thrown.

The current API behaves the same as a Java class file. A class file
that accesses B.foo will cause a runtime error when executed with a
class file for B that no longer declares a "foo" field. You can think
of the Reflection API as being post compilation, like a class file is.
Some other dispatch mechanism as already determined the exact member
to access and we just want to get at it. We don't want to apply
another dispatch mechanism as a necessary part of accessing the
specified member.

> Everywhere else in Joe-E, fields inherited from the superclass are
> treated the same as fields declared in the class itself.  For instance,
> the expression "o.f" refers to the field f, whether f is declared by o
> itself or is inherited from one of o's superclasses.

That's because the Java compiler is doing the dispatch for you. What
if you've already done the dispatch via some other mechanism and you
just want to apply its results?

> To put it another way, if the result of "fields(false, class)" includes
> a field whose name is f, then I think "field(false, class, f)" should
> return that field, for purposes of uniformity.  I think that the set of
> fields that fields() returns should be the same set of possible fields
> that field() looks at when it does its lookup.

The uniformity is for each field "f" returned by fields(instance,
class), the following is true:

f.equals(field(instance, f.getDeclaringClass(), f.getName()))

> After reading Waterken code, I understand why Tyler did it this way for
> Waterken, but I think this is the wrong interface for a general-purpose
> Joe-E library.

I use these semantics in the Waterken Server because a remote client
has already determined exactly what member it wants to access and the
server is just supposed to access it. The dispatch has already been
done by the client. The server is not supposed to (possibly) change
the meaning of the client's request. I suspect this pattern will hold
whenever objects are passing around reflected code members.

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/