Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #29710
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Accessibility of suBclass-fields from suPERclass (reflection) |
| Date | 2014-08-17 15:24 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <lsqvi4$t4i$1@dont-email.me> (permalink) |
| References | (2 earlier) <slrnluu6ir.fp3.avl@login.logic.tuwien.ac.at> <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> |
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);
}
? This is way wordier than using an EnumMap, *and* it prevents rather
than enables compile-time checking -- did you spot the typo?
I'm confident that you've got a credible use case, but I'm less
confident that you've got a credible use case for this technique. If
you'd reveal a little more about the larger problem, perhaps someone
could suggest an alternative approach -- that might even turn out to
be a better choice all around.
--
esosman@comcast-dot-net.invalid
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