Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #29711
| From | Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Accessibility of suBclass-fields from suPERclass (reflection) |
| Date | 2014-08-17 21:35 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <slrnlv2813.fp3.avl@login.logic.tuwien.ac.at> (permalink) |
| References | (3 earlier) <c58q1fF9v1tU1@mid.individual.net> <slrnluvn8q.fp3.avl@login.logic.tuwien.ac.at> <lsosjs$gtc$1@dont-email.me> <slrnlv1rkm.fp3.avl@login.logic.tuwien.ac.at> <lsqvi4$t4i$1@dont-email.me> |
Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> On 8/17/2014 2:04 PM, Andreas Leitgeb wrote:
>> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>>> On 8/16/2014 6:37 PM, Andreas Leitgeb wrote:
>>>> I have a special Base class, and each of its subclasses serve exactly
>>>> one purpose: a collection of name/value associations where the java-
>>>> compiler knows about the valid names, so as to detect accesses to
>>>> non-existing names already at compile-time. (without that last premise,
>>>> I would have used HashMaps instead of subclasses)
>>> Would an EnumMap serve?
>> In principle yes, but...
>> ... element-access would look like:
>> someSpecificEnumMapInstance.get( SomeSpecificEnum.itemName )
>> instead of:
>> someSpecificSubClassInstance.itemName
>
> We can all bemoan Java's occasional wordiness, but wasn't your
> original code something like
>
> Value value;
> try {
> Field f = someSpecificSubClassInstance
> .getClass().getField("itenName");
> f.setAccessible(true); // if needed
> value = (Value) f.get(someSpecificSubClassInstance);
> } catch (NoSuchFieldException | SecurityException | ... ex) {
> throw SelfInflictedWoundException(ex);
> }
That's a funny collage of a couple of separate snippets I mentioned in
separate posts :-) Of course, the base class in my case doesn't
hardcode any field names as String-literals. That was only to give
some context for setAccessibility.
The code involving setAccessibility() exists only once, whereas accessing
those fields directly as foo.bar happens lots of times.
This thread is actually finished already, as I found a probable answer
to my own question: reflection just doesn't know/care where it is called
from, so it can't make any special cases for base classes. It's default
view on accessibility is solely based on target class's public'ness.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-15 00:58 +0000
Re: Accessibility of suBclass-fields from suPERclass (reflection) Lew <lewbloch@gmail.com> - 2014-08-15 15:20 -0700
Re: Accessibility of suBclass-fields from suPERclass (reflection) Steven Simpson <ss@domain.invalid> - 2014-08-16 00:11 +0100
Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-16 00:10 +0000
Re: Accessibility of suBclass-fields from suPERclass (reflection) Arne Vajhøj <arne@vajhoej.dk> - 2014-08-15 23:26 -0400
Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-16 08:46 +0000
Re: Accessibility of suBclass-fields from suPERclass (reflection) Robert Klemme <shortcutter@googlemail.com> - 2014-08-16 12:27 +0200
Re: Accessibility of suBclass-fields from suPERclass (reflection) "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-16 13:37 +0100
Re: Accessibility of suBclass-fields from suPERclass (reflection) Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-16 09:47 -0400
Re: Accessibility of suBclass-fields from suPERclass (reflection) Robert Klemme <shortcutter@googlemail.com> - 2014-08-17 13:19 +0200
Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-16 22:37 +0000
Re: Accessibility of suBclass-fields from suPERclass (reflection) Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-16 20:22 -0400
Re: Accessibility of suBclass-fields from suPERclass (reflection) Josip Almasi <joe@vrspace.org> - 2014-08-17 12:51 +0200
Re: Accessibility of suBclass-fields from suPERclass (reflection) Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-17 07:54 -0400
Re: Accessibility of suBclass-fields from suPERclass (reflection) "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-17 13:44 +0100
Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-17 17:42 +0000
Re: Accessibility of suBclass-fields from suPERclass (reflection) Arne Vajhøj <arne@vajhoej.dk> - 2014-08-18 20:45 -0400
Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-20 18:47 +0000
Re: Accessibility of suBclass-fields from suPERclass (reflection) Josip Almasi <joe@vrspace.org> - 2014-08-18 17:19 +0200
Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-17 18:04 +0000
Re: Accessibility of suBclass-fields from suPERclass (reflection) Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-17 15:24 -0400
Re: Accessibility of suBclass-fields from suPERclass (reflection) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-17 21:35 +0000
Re: Accessibility of suBclass-fields from suPERclass (reflection) Josip Almasi <joe@vrspace.org> - 2014-08-16 12:31 +0200
Re: Accessibility of suBclass-fields from suPERclass (reflection) Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-16 10:51 -0400
Re: Accessibility of suBclass-fields from suPERclass (reflection) Arne Vajhøj <arne@vajhoej.dk> - 2014-08-16 11:00 -0400
csiph-web