ooc-dev team mailing list archive

[Noel Cower <ncower@xxxxxxxxx>]

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