--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > No need-the "gotcha" site you gave earlier did
> give
> > some specific drawbacks under string compares:
> >
> > http://mindprod.com/jgloss/gotchas.html#COMPARISON
>
> That's not a drawback. Interned strings allow
> comparision of
> references:
> String a="a".intern();
> String b="a".intern();
> if(a==b) { System.out.println("equal"); }
> With non-interned strings you need a.equals(b),
> which
> may be slower, for longer strings anyway.
>
> The most important gotcha is that interned strings
> may lock
> up memory forever.
Yes, I may have misread that--outside of the fact that
strings are not GC'ed away, the intern() function does
not look that bad (their mention of a possible 64K
limit may be an issue if we also keep property values,
however.) Still, I still don't know enough at this
stage to rule out any particular design.
> If interning is done only for
> property
> names and enumeration tokens (in contrast to
> property values),
> this may be acceptable.
>
If we just do that, I believe we're back to
enumeration tokens, which don't need intern() anyway.
I think the next thing to consider is the storage of
specified vs. computed values. Let's say we store
pointers for many properties to the same
{"property-name", "property-value"} pair. A specified
property value of "10%" would not make this a very
helpful data structure if that percentage resolves to
different computed values for each property sharing
this pair. I believe the goal for us then would be
just store the computed value for each pair (meaning
many more pairs), as long as we take into account the
can't-resolve-everything-without-knowledge-of-layout
issue.
Glen
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
