Creating immutable sorted sets from already-ordered data about guava HOT 10 CLOSED

Original comment posted by kevinb9n on 2009-03-17 at 05:09 PM

This idea needs a lot more thought.

Case 1: you can provide a comparator. In this case, you should provide it -- and just
create an ImmutableSortedSet. Creating that will cause a sort() to happen which will
be a no-op, and that's not great but not terrible. It's possible we could provide
another way to create an ISS where you declare your data is already increasing, thus
the factory only has to check that each element is higher than the one before it, and
doesn't have to call sort(). Meh.

Case 2: you can't provide a comparator. Some complicated database sort was done, for
instance. So your comparator becomes an Ordering.givenOrder() over the elements you
have. ImmutableSortedSet.inGivenOrder().addAll(list).build(). I kind of like this,
but I haven't heard a loud demand for it. (then again, many people are not loudly
demanding it but are still returning List from APIs that really should be Sets.)

from guava.

Original comment posted by jared.l.levy on 2009-08-13 at 02:06 PM

There's a problem with Case 2. Without a comparator, you can't implement the
comparator(), headSet(), tailSet(), and subSet() methods.

from guava.

Original comment posted by jim.andreou on 2009-08-13 at 02:20 PM

Could you elaborate on that a bit? E.g. why Ordering.givenOrder()/.explicit() wouldn't
do?

from guava.

Original comment posted by kevinb9n on 2009-08-13 at 02:43 PM

Yeah, those methods would only be able to accept values that are elements in the set,
so they'd be a bit crippled, but I'm not sure it's a deal-breaker.

This whole idea still lacks real motivation from users.

from guava.

Original comment posted by jim.andreou on 2009-08-13 at 03:05 PM

Hmm, alright. Though it wouldn't be any more "crippled" than Ordering.explicit()
itself. And you already decided that it doesn't pay off enough to allow defining what
happens with elements not contained in the list (with something similar to
nullsFirst()/nullsLast()), with which I agree, so I don't see this as a big issue - but
the real deal-breaker would be indeed lack of enough demand :)

from guava.

Original comment posted by leonidos on 2009-09-03 at 07:21 PM

ImmutableSortedSet should guarantee that its items are ordered using the comparator()
order, so it's a good idea to accept the client assumption (that items are already
ordered). But, I think, an acceptable case when the order is checked at the
construction phase - so ImmutableSortedSet.copyOfSorted(List<E> list) can check the
given list to be correct, and accept it if correct or throw an exception if not.

from guava.

Original comment posted by leonidos on 2009-09-10 at 01:36 PM

[erratum]
In the previous message - I meant "it's not a good idea accept the client assumption".

from guava.

Original comment posted by kevinb9n on 2009-09-17 at 06:02 PM

(No comment entered for this change.)

Labels: Milestone-Post1.0

from guava.

Original comment posted by jared.l.levy on 2010-02-16 at 07:11 PM

I just added ImmutableSortedSet.withExplicitOrder() methods to Google's internal code
base. It will probably be in a future Guava release.

Status: Fixed
Owner: jared.l.levy

from guava.

The issue says it's fixed, but it doesn't appear to be a possibility in recent versions of Guava. It would be a really useful functionality. Is there a reason not to have this?

from guava.