Return-Path: 
 <user-return-1295-apmail-pivot-user-archive=pivot.apache.org@pivot.apache.org>
Delivered-To: apmail-pivot-user-archive@www.apache.org
Received: (qmail 21101 invoked from network); 19 Apr 2010 14:27:51 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 19 Apr 2010 14:27:51 -0000
Received: (qmail 1301 invoked by uid 500); 19 Apr 2010 14:27:51 -0000
Delivered-To: apmail-pivot-user-archive@pivot.apache.org
Received: (qmail 1273 invoked by uid 500); 19 Apr 2010 14:27:51 -0000
Mailing-List: contact user-help@pivot.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@pivot.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@pivot.apache.org>
List-Post: <mailto:user@pivot.apache.org>
List-Id: <user.pivot.apache.org>
Reply-To: user@pivot.apache.org
Delivered-To: mailing list user@pivot.apache.org
Received: (qmail 1265 invoked by uid 99); 19 Apr 2010 14:27:51 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Apr 2010 14:27:51 +0000
X-ASF-Spam-Status: No, hits=0.9 required=10.0
	tests=PLING_QUERY,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [80.67.31.26] (HELO smtprelay03.ispgateway.de) (80.67.31.26)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Apr 2010 14:27:40 +0000
Received: from [80.67.16.112] (helo=localhost)
	by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.68)
	(envelope-from <dmoebius@scoop-gmbh.de>)
	id 1O3rwV-0006HD-SK
	for user@pivot.apache.org; Mon, 19 Apr 2010 16:27:19 +0200
Received: from 195.243.208.50 ([195.243.208.50]) by www.premium-webmail.de
 (Horde Framework) with HTTP; Mon, 19 Apr 2010 16:27:19 +0200
Message-ID: <20100419162719.11096g26f9pnavgo@www.premium-webmail.de>
Date: Mon, 19 Apr 2010 16:27:19 +0200
From: Dirk =?iso-8859-1?b?TfZiaXVz?= <dmoebius@scoop-gmbh.de>
To: user@pivot.apache.org
Subject: Re: let Sequence<T> extend Iterable<T> ?!?
References: <20100419121602.509349jzue8ktjsw@www.premium-webmail.de>
 <37CF7D4B-6ED3-48AB-80DC-40A99231F57A@mac.com>
 <20100419141642.10608d0zs3wp5cx4@www.premium-webmail.de>
 <65674B09-B3A9-4EE1-AE06-EB6072167844@mac.com>
In-Reply-To: <65674B09-B3A9-4EE1-AE06-EB6072167844@mac.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=ISO-8859-1;
 DelSp="Yes";
 format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.2)
X-Originating-IP: 195.243.208.50
X-Df-Sender: 110773
X-Virus-Checked: Checked by ClamAV on apache.org

Greg Brown <gkbrown@mac.com> wrote:
>>> This approach allows us to combine collection behaviors without  
>>> collisions on the Iterable type (for example,  
>>> org.apache.pivot.xml.Element implements List<Node> and  
>>> Dictionary<String, String>, which wouldn't compile if Dictionary  
>>> also implemented Iterable).
>>
>> I didn't suggest that Dictionary<K,V> should implement Iterable.
>> I would not be feasible anyway: should it iterate on the keys or the values?
>
> Map<K, V> iterates over keys (since it extends Collection<K>).
>
> Pivot's collections all follow the same pattern:
>
> List<T> : Sequence<T>, Collection<T>
> Map<K, V> : Dictionary<K, V>, Collection<K>
> Set<E> : Group<E>, Collection<E>

I see. I still fail to see the collision, but I see now that you have  
a different understanding, or rather a different "vision", of how a  
collection library should look like. See, my understanding is that  
(almost) everything is a sequence, with maps being sequences of pairs,  
and a collection is an enhanced sequence which can be updated. So IMHO  
it would look like this:

   List<T> extends Sequence<T> extends Iterable<T>, Collection<T>
   Map<K, V> extends Dictionary<K, V> extends Sequence<Pair<K,V>>,  
Collection<K>
   Set<E> extends Group<E> extends Iterable<E>, Collection<E>

But I'm not a library designer, so I should probably keep my mouth  
shut. I'll stop babbling about it and won't raise this issue again.  
Thanks, Greg, for your detailed explanations!

> It wouldn't make sense to make Sequence iterable

You're the first person I get to know who says that sequences are not  
iterable. ;-)

>> Iterating over a list using indices is sooo 90ies. Why can't I simply write:
>> for (Object row : tableView.getSelectedRows()) {
>>  ...
>> }
> That's true, but getSelectedRows() is primarily meant to be a  
> convenience method. The primary means of obtaining a table view's  
> selection is getSelectedRanges(). This method returns an instance of  
> ListSelectionSequence, which could (and probably should) implement  
> Iterable.

That's ok, it would help in this case. Note that you need to make  
getSelectedRanges() return ListSelectionSequence instead of  
Sequence<Span>. And ListSelectionSequence needs to be public. (And,  
btw., you are making just one more class, which is implementing  
Sequence directly (but not List), implement Iterable. ;-)

Please don't forget ListView.getSelectedRanges(), too.
Uh, and TreeView.getSelectedPaths(). And  
FileBrowser(Sheet).getSelectedFiles().

> You might suggest that getSelectedRows() return a List. We don't do  
> this because it might imply that the return value is a "live"  
> collection to which the caller can listen for updates, which is not  
> the case.

So you're saying that any list that is not "live" is a sequence and is  
not iterable?!? That's odd. (Sorry, can't stop :-)

Regards,
Dirk.