[e-lang] Joe-E reflection API questions

[David Wagner]

Tyler Close writes:
>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.

Thanks for the explanation.  I see.  This is tricky because, in Java,
fields in a subclass hide fields in the superclass; they don't override.

How would you feel about having field(instance, X.class, "foo") return
X's foo if it has one, otherwise look up the inheritance hierarchy to
find the first superclass of X that declares a foo and return that one?

For instance, under this proposal:

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

field(instance, A.class, "foo") ==> A.foo
field(instance, B.class, "foo") ==> A.foo
field(instance, C.class, "foo") ==> C.foo
field(instance, D.class, "foo") ==> C.foo

Right now, I believe the behavior is

field(instance, A.class, "foo") ==> A.foo
field(instance, B.class, "foo") ==> throws NoSuchMember
field(instance, C.class, "foo") ==> C.foo
field(instance, D.class, "foo") ==> throws NoSuchMember

Under this proposal,

z = field(instance, Y.class, "foo").get(x);

would be equivalent to

z = ((Y)x).foo;

if the latter compiles (otherwise the former would throw).

As a special case,

z = field(instance, x.getClass(), "foo").get(x);

would be equivalent to

z = x.foo;

if the latter compiles (otherwise the former would throw).

This proposal would preserve your desired property that for
each field "f" returned by fields(instance, class), the following
is true:

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

It would also be consistent with your use case in Waterken, where
the client has already fully resolved the dispatch.