ooc-dev team mailing list archive
-
ooc-dev team
-
Mailing list archive
-
Message #00164
Re: Back/front methods for Iterable (and reverse iterators)
>
> Adding methods to powerfull baseclasses and then allow them to throw
> exceptions when not supported is horrible, why have static type checking
> when basic stuff in the framework is designed to only be discovererable if
> it is correct at runtime, instead of by the compiler ?
Agreed. I hate that too - but I also hate big, convoluted class hierarchies.
We're just throwing ideas in the air right now - at least it's off my head
now.
On Sat, May 29, 2010 at 8:53 PM, Bart van der Werf <bluelive@xxxxxxxxx>wrote:
> What about:
>
> selectWinners: func (clients: List<Client>) {
> deluxeLimit := 10
> winners := ArrayList<Client> new()
> losers := ArrayList<Client> new()
>
> winners addRange(clients take(deluxeLimit))
> losers addRange(clients skip(deluxeLimit))
>
> }
>
Please define addRange (also - why the heck? wouldn't addAll() work with a
RangeList ?), define take, define skip. What the heck do they do, and are
they even useful for another case than this one?
Amos.
>
> On Fri, May 28, 2010 at 11:31 PM, Amos Wenger <amoswenger@xxxxxxxxx>wrote:
>
>> (damn Enter key that sends in GMail..)
>>
>>
>> The 'iterators are iterable' idiom is particularly useful in cases like
>> that:
>>
>> selectWinners: func (clients: List<Client>) {
>> iter := clients forward()
>> deluxeLimit := 10
>> winners := ArrayList<Client> new()
>> losers := ArrayList<Client> new()
>>
>> for(c in iter) {
>> winners add(c)
>> if(winners size() >= deluxeLimit) break
>> }
>>
>> // continue attributing people.
>> for(c in iter) {
>> losers add(c)
>> }
>> }
>>
>> Amos
>>
>>
>> On Fri, May 28, 2010 at 11:29 PM, Amos Wenger <amoswenger@xxxxxxxxx>wrote:
>>
>>> Maybe we should have
>>>
>>> - iterator()
>>> - backIterator() (can throw exception if unsupported)
>>> - forward() == iterator()
>>> - backward() == backIterator() reverse()
>>>
>>> The 'iterators are iterable' idiom is particularly useful in cases like
>>> that:
>>>
>>> selectWinners: func (c: List<Clients>) {
>>> deluxeLimit := 10
>>>
>>>
>>> On Fri, May 28, 2010 at 10:20 PM, Noel Cower <ncower@xxxxxxxxx> wrote:
>>>
>>>> I like Josh and Rubin's ideas, although I think forward and backward
>>>> don't really communicate that the iterator is going to be at one end or the
>>>> other of the list. Not all iterables are going to have the ability to go
>>>> forward/backward, so it would make sense, to me at least, to put those in
>>>> List, but then things like HashMap, which are iterable and can have reverse
>>>> iteration, won't have those methods.
>>>>
>>>> Maybe another subclass of Iterable is necessary to give List and HashMap
>>>> the same backing without having them be treated as different in terms of
>>>> their ability to iterate forwards/backwards? Like BidirectionalIterable or
>>>> EndedIterable (the former being too long and the latter seems a little odd
>>>> to me).
>>>>
>>>> If we do use forward/backward, should backward always be a reverse
>>>> iterator?
>>>>
>>>> Also, iterable iterators sound nice, and I don't really see why we ought
>>>> to not do that - wouldn't cost anything, just have the iterator return
>>>> itself when iterator() is called.
>>>>
>>>> -noel
>>>>
>>>> On May 28, 2010, at 9:48 AM, Amos Wenger wrote:
>>>>
>>>> I like the proposal of Rubin.
>>>>
>>>> Maybe iterator should be iterable? (they would just return themselves)
>>>>
>>>> In that case we could write:
>>>>
>>>> for(element in list backward())
>>>>>
>>>>
>>>> And ex-Java programmers could even write
>>>>
>>>> for(element in list forward())
>>>>>
>>>>
>>>> If they wanted.
>>>>
>>>> Amos
>>>>
>>>> On Fri, May 28, 2010 at 5:59 PM, cd rubin <launchpad@xxxxxxxxxxxxxxxx>wrote:
>>>>
>>>>>
>>>>> Hey all
>>>>>
>>>>> In which case shouldn't the methods be called 'forwards' and
>>>>> 'backwards'? I think that fits better with the language :
>>>>>
>>>>> "iterate over a list backwards"
>>>>>
>>>>> iter := list backwards()
>>>>>
>>>>> and it removes possible confusion stemming from calling the method
>>>>> 'front' and getting an iterator instead of the first item of the list!
>>>>>
>>>>> - Daniel (cdrubin)
>>>>>
>>>>> On Fri, May 28, 2010 at 11:21 AM, Josh Roesslein <jroesslein@xxxxxxxxx
>>>>> > wrote:
>>>>>
>>>>>> Bart makes a good point that not all Iterables will have an ordered
>>>>>> structure (ex: socket input/output streams).
>>>>>> I think it would make more sense having front() and back() methods in
>>>>>> List that returns Iterators that either traverse
>>>>>> the list head to tail or vice versa.
>>>>>>
>>>>>> Josh
>>>>>>
>>>>>> On Fri, May 28, 2010 at 9:33 AM, Amos Wenger <amoswenger@xxxxxxxxx>wrote:
>>>>>>
>>>>>>> So what then? iterator~back() ?
>>>>>>>
>>>>>>>
>>>>>>> On Fri, May 28, 2010 at 2:53 PM, Bart van der Werf <
>>>>>>> bluelive@xxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> I'm not sure.
>>>>>>>>
>>>>>>>> Alot of iterables have no order, so if front/back is the default way
>>>>>>>> to get an iterator it would make little sense.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
>>>>>>> Post to : ooc-dev@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
>>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
>>>>>> Post to : ooc-dev@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
>>>>> Post to : ooc-dev@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
>>>> Post to : ooc-dev@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~ooc-dev<https://launchpad.net/%7Eooc-dev>
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ooc-dev
>> Post to : ooc-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ooc-dev
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
Follow ups
References
-
Back/front methods for Iterable (and reverse iterators)
From: Noel Cower, 2010-05-25
-
Re: Back/front methods for Iterable (and reverse iterators)
From: Amos Wenger, 2010-05-27
-
Re: Back/front methods for Iterable (and reverse iterators)
From: Bart van der Werf, 2010-05-28
-
Re: Back/front methods for Iterable (and reverse iterators)
From: Amos Wenger, 2010-05-28
-
Re: Back/front methods for Iterable (and reverse iterators)
From: Josh Roesslein, 2010-05-28
-
Re: Back/front methods for Iterable (and reverse iterators)
From: cd rubin, 2010-05-28
-
Re: Back/front methods for Iterable (and reverse iterators)
From: Amos Wenger, 2010-05-28
-
Re: Back/front methods for Iterable (and reverse iterators)
From: Noel Cower, 2010-05-28
-
Re: Back/front methods for Iterable (and reverse iterators)
From: Amos Wenger, 2010-05-28
-
Re: Back/front methods for Iterable (and reverse iterators)
From: Amos Wenger, 2010-05-28
-
Re: Back/front methods for Iterable (and reverse iterators)
From: Bart van der Werf, 2010-05-29