Re: [Hibernate-devel] volunteers?

[Gavin_King/Cirrus%<CI...@ci...>]

Yeah, I _had_ been drawing a distinction between PersistentCollections,
which represent actual collections on the database, and things like
entrysets, iterators, subsets which represent a view of a persistent
collection. The two things are conceptually different even though,
as you suggest, we could share some code between them. Right now I'm
tending to favor continuing the distinction and _not_ sharing code.

I committed a refactor of the SortedSet code to CVS, for you to have a
look at. We can always roll back to what you had.....

the previous version is tagged v096.

I also committed some probably-badly-concieved code which would let you
make a subset persistent (with all kinds of caveats!)

Gavin

> Please compare your Map.SetProxy with my SortedSet.SubSet
> implementations (and the corresponding differences in your
> PeriststentCollection.IteratorProxy and my SortedSet.WrapIterator).

> I felt squeamish about having a null session in the SubSet (and I'm
> not sure if I need to handle getInitialValue and setSession in the
> SubSet -- I assume not, since the SubSet is already materialized and
> the session has no handle on it). But the advantage of my approach is
> much more code sharing between SubSet and SortedSet (and Set). This
> will be even more pronounced in the SortedMap implementation -- so
> I'll hold off on implementing that until I get your guidance on the
> direction to take.

> An alternative compromise between the two approaches is to add an
> instance variable to SortedSet, backingSet, which would be null for
> the real set, and for subsets it would reference the SortedSet
> superset. Then write() and read() could check backingSet: if it's null
> they would do the usual thing, if not they would delegate. This would
> be compatable with PeristentCollection.IteratorProxy I think.