[e-lang] Joe-E reflection API questions

[David Wagner]

Mark Miller writes:
>As far as I can tell, the attached Reflection class exports only safe
>and sensible operations. I propose that it, or something of similar
>functionality, be made available as part of the Joe-E library. Neither
>Tyler nor I could adequately remember the nature of previous
>controversies about this API. Since I do need some of this for Horton,
>and Tyler needs some (all?) of this for reconstructing the waterken
>web_send library on top of the new ref_send API, let's please argue
>through these remaining controversies. Thanks.

I'll restrict my comments to the public interface of Reflection.
If we can agree on the desired semantics of the API, then I'll go
back and look at the implementation again.  Here were the comments
that I made before that I think are worth discussing.  Given that
you and Tyler have experience programming to this interface, and
I don't, I think your views should be weighted more highly than
mine, but I'm curious to hear your reactions to the comments below.


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.

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.

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.

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.



Comment: I have the same comment about non-uniformity in method()
vs methods().  methods() includes inherited methods; method() ignores
inherited methods.  method() should not ignore inherited methods.



Comment: We could make the type signature for constructors()
genericized, e.g.,
  <T> public static PowerlessArray<java.lang.reflect.Constructor<T>>
        constructors(java.lang.Class<T> type)
Tyler points out that it's not clear this would ever make any
difference, since if you knew the type T at compile time, maybe you
wouldn't be using reflection.  I don't have any example where this
is necessary or useful, so probably this can be ignored and added
later if we ever need it.