What would be the best way to implement "sublists"?
monster
wanted to use primitive collections in Protostuff instead of
Collections of wrappers. I've submitted a new template so Protostuff
can soon support HPPC.
So, for my questions:
1) I've been looking at the automatically decompiled code in
Eclipse... Why are almost all methods of XXXArrayList classes final
*except* "public void add(XXX value)" ?
2) How could I implement sublists similar to JCF sublists on top of
the XXXArrayLists? It does not seem to be a functionality currently
offered. If I have to re-implement it for every primitive type, that
would be a lot of duplicated code. My use-case is that I simulate a
two-dimensional read-only List-of-list, but using a single array for
the data, plus another for pointing to the "end" of the list-value at
position N. Being able to return a read-only view to a small portion
of an array-list would make things possible like calling toArray() on
that portion only.
3) Would it hurt performance to split the interfaces, like
IntIndexedContainer, in read-only and read-write? If the read-write
interface extends the read-only interface, then there should be no
compatibility problem with existing code, and it makes implementing
read-only sublists easier than full-blown read-write sublists.
Dawid Weiss
> can soon support HPPC.
Awesome, thanks!
> 1) I've been looking at the automatically decompiled code in
> Eclipse... Why are almost all methods of XXXArrayList classes final
> *except* "public void add(XXX value)" ?
Good question, I don't know :) In reality, they should _not_ be final,
really -- the point of HPPC is so that folks can alter the defaults if
they feel like it. If they don't, the hotspot will usually do dynamic
type checks and infer that a given method has no overrides (and make
it effectively final and suitable for inlining). We should review and
remove those final markers, I'll add an issue.
> 2) How could I implement sublists similar to JCF sublists on top of
> the XXXArrayLists? It does not seem to be a functionality currently
> offered. If I have to re-implement it for every primitive type, that
> would be a lot of duplicated code. My use-case is that I simulate a
> two-dimensional read-only List-of-list, but using a single array for
> the data, plus another for pointing to the "end" of the list-value at
> position N. Being able to return a read-only view to a small portion
> of an array-list would make things possible like calling toArray() on
> that portion only.
A short answer is that HPPC is not a replacement for Java's
Collections, so not everything is included. Delegate decorators like
the one you're describing add another layer of calls and are not
really what we're after. You could do
the above by creating another list and copying the internal slice of
the buffer (but this wouldn't be shared). This isn't politically
correct since I should promote HPPC, but if you need full collections
support you can also peek at fastutil library -- they have wrappers
for just about every collections interface, including sublists.
> 3) Would it hurt performance to split the interfaces, like
> IntIndexedContainer, in read-only and read-write? If the read-write
> interface extends the read-only interface, then there should be no
> compatibility problem with existing code, and it makes implementing
> read-only sublists easier than full-blown read-write sublists.
It probably wouldn't hurt performance but I don't see the point
(discussion above). Note that, for example, IntArrayList has a buffer
but the start offset is always fixed to 0; to have sublists you would
have to implement non-zero start offset and this again would make the
code more complex. Also, the read-only interface to iterate over a
container is there -- it's IntContainer. Granted, it doesn't have
random access but then if you have a concrete scenario in which
nothing in HPPC fits you can still just grab and use access to the
internals (and design any interfaces you wish on top of them).
Dawid