Sized

[Brian Goetz]

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
>