[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: possible bug in TreeMap.sucessor implementation
From: |
Dalibor Topic |
Subject: |
Re: possible bug in TreeMap.sucessor implementation |
Date: |
Sun, 22 Dec 2002 06:01:01 -0800 (PST) |
--- Eric Blake <address@hidden> wrote:
> Dalibor Topic wrote:
> >>Since nil is supposed to have children that are
> also
> >>nil it appears
> >>that at some point nil.right was assiged a value.
>
> >
> >
> > would it be possible to make nil an
> "ImmutableNode",
> > so that such assignments are caught and greeted
> with
> > an Error? that should make your life easier next
> time
> > you have to debug a similar case.
>
> For debugging, yes. For efficiency, no. Creating
> an ImmutableNode
> would require reworking the entire TreeMap class to
> use method calls,
> rather than field assignments, for manipulating
> nodes. Adding
> polymorphic calls is an additional layer of
> indirection, and will make
> the overall implementation slower.
Just a hypothetical question: wouldn't it be possible
for an inlining (JIT-) compiler to inline the
setter/getter calls if ImmutableNode was private
final, and the setter/getter methods too? I'm dreaming
of inlining class loaders ;)
cheers,
dalibor topic
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com