ooc-dev team mailing list archive

[Bart van der Werf <bluelive@xxxxxxxxx>]

ListIterable to the rescue which add reverseIterator() ?

On Sat, May 29, 2010 at 10:42 PM, Noel Cower <ncower@xxxxxxxxx> wrote:

> The addRange stuff is nice and all, but I'd really like to get this
> front/back business done with first, since I'd like to have those while
> writing NUIT and not have to ask others to grab my custom SDK (either that
> or I'm going to reimplement Iterable and LinkedList and such just for NUIT,
> and I really do not want to do that if I can avoid it).  That being said, I
> like having iterator/backIterator/forward/backward for names, so unless
> someone disagrees with that, I think I'd like to go with that and call the
> naming settled.
>
> I don't particularly like having methods in Iterable that won't/can't be
> implemented in certain subclasses, so I think the only options are to either
> a) have a subclass of Iterable that does include these features or b) do it
> anyway and let them throw exceptions.  If there's an option #3 that's better
> than having to individually define these methods for every subclass of
> iterator that has them, then I'd also like to hear/read that.
>
> -noel
>
> On May 29, 2010, at 12:07 PM, Bart van der Werf wrote:
>
> 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:
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>
>
>