ooc-dev team mailing list archive

[Bart van der Werf <bluelive@xxxxxxxxx>]

addRange: yeah the name sucks, addAll works too.

addRange takes and iterable or iterator, walks it and adding all elements to
the collection.

skip and take are methods on an iterable, returning an iterable.
skip skips the first n elements from the input.
take only returns the first n elements from the input
(the returned iterables are lazy, so skip doesn't copy the source iterable,
but is just a facade)

On Sat, May 29, 2010 at 8:56 PM, Amos Wenger <amoswenger@xxxxxxxxx> wrote:

> 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
>>>
>>>
>>
>