← Back to team overview

ooc-dev team mailing list archive

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