[e-lang] Joe-E reflection API questions

[Mark Miller]

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.

Some other options:

1) rename field() to declaredField(), following the Java reflection
naming convention.

2) have all four: field(), fields(), declaredField(), declaredFields().

3) Add another boolean flag (in addition to the current static-vs-instance flag)


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

Actually, it's a bit weirder than that: methods(Reflection.instance,
...)  includes inherited methods, but methods(Reflection.statics, ...)
does not.


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

For obvious reasons, constructor() and constructors() both ignore
inherited inherited constructors. So at least one could do what you
suggest without worrying about co/contra-variance.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM