Sized

[Kevin Bourrillion]

All right, all right. Exiting pain in the ass mode. I can get behind "Sized
means it has a size() method, plain and simple."

To the extent that I think Iterable should extend it (which I'm still
trying to convince myself one way or the other of), I can still just save
that argument for another day.

Seems a fine plan. I assume Map will extend it, and a future version of
Guava that worked with JDK 8 would have Multimap, etc. extend it too.
(Multisets in particular have wound up wanting to be long-sized many a
time.)


On Mon, Nov 5, 2012 at 3:48 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

The real purpose is as I specified earlier -- providing a migration path
> for the 32-bit size limitation that is hard-coded into Collections.  There
> are a number of size-like methods in new APIs and I want to select neither
> of the following signatures:
>
>   int size()
>   long size()
>
> Instead, I want to make a choice based on a framework for migration
> towards 64-bit collections.  The Sized I proposed was one possible way to
> do this in an organized way.  But this was all in the first message on this
> thread?
>
> On Nov 5, 2012, at 6:33 PM, Kevin Bourrillion wrote:
>
> I think you're implying that size() doesn't make sense for such an
> Iterable. Correct?
>
> But why not? You're describing an (imho sociopathic, but that's beside the
> point) iterable that is content to be destroyed upon a single use. Calling
> size() would just be one of the ways to use it and destroy it. I see
> nothing inconsistent about that.
>
> While it probably seems like I'm just trying to be a pain -- probably
> seems a *lot* like that -- all I'm after is some clear way to explain the
> purpose of this new type, that makes it make sense to people when they
> should use it and when they shouldn't. I'm asking questions to understand
> this rationale so that I can explain it myself. But I'm just not following
> it yet.
>
>
> On Mon, Nov 5, 2012 at 3:15 PM, Brian Goetz <brian.goetz at oracle.com>wrote:
>
>> Iterable doesn't guarantee that you can iterate the source more than
>> once.  It is entirely consistent with the Iterable spec that iterator()
>> always returns the same Iterator.
>>
>> On Nov 4, 2012, at 10:31 AM, Kevin Bourrillion wrote:
>>
>> 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
>>
>>
>>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>
>
>


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