Sized

[Brian Goetz]

So, what I was really hoping for was feedback on this approach to 
providing a migration path from 32 to 64 bit collections (and 
collection-like things).  Any feedback?

On 11/5/2012 7:10 PM, Kevin Bourrillion wrote:
> 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
> <mailto: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 <mailto: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 <mailto: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 <mailto:kevinb at google.com>
>>>
>>
>>
>>
>>
>>     --
>>     Kevin Bourrillion | Java Librarian | Google,
>>     Inc. |kevinb at google.com <mailto:kevinb at google.com>
>>
>
>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
> <mailto:kevinb at google.com>
>