Sized

Kevin Bourrillion kevinb at google.com
Sun Nov 4 07:31:58 PST 2012


On Fri, Nov 2, 2012 at 3:53 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

I think you're focusing on another problem.  These things *have* size()
> methods already; I'm trying to capture this in a finer-grained interface.
>  The "size in O(1) time" is a whole orthogonal concern.
>

Sorry -- I was just going off the initial description, "It is useful to
indicate that an aggregate knows its size."  If the real goal instead is
only to distinguish when an aggregate "decides to expose a size() operation
for *whatever* reason", then right, there's no problem here.

But this new understanding doesn't make clear the reason why Iterable
shouldn't go ahead and extend Sized as well. As Mike says, it "can
determine it's size and that size() implementation is at least as good as
getting an iterator and counting the items" -- that's undeniably the case.
And as you say, the performance question is orthogonal.

But I think you don't want that, so I am still missing what the distinction
between Sized and not Sized is supposed to be.


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com


More information about the lambda-libs-spec-observers mailing list