« Return to Thread: Towards a revised collection API
Re: Towards a revised collection API
by Jamie Webb-2
::
Rate this Message:
On 2008-04-18 12:28:38 David MacIver wrote:
> So, with the recent noise I've been making about the collections API,
> I figured I should put some thoughts down on screen.
>
> As I see it one of the main problems with the current collection API
> is that in order to make things play nicely you need to override
> methods at every step of the way. map, filter, flatMap etc all return
> the "wrong" things. This is a pain to write and easy to get wrong.
This is what Martin is talking about fixing with type constructor
polymorphism, which seems preferable by far.
> The other thing I don't like about the collections API is that I'm not
> a big fan of iterators. They're really cumbersome to create for custom
> collection types and are designed around a really irritating "check
> then proceed" style. Really all we care about is how to traverse the
> data structure, and constructing an iterator to do so is often not the
> best way.
Agreed. See scalax.control.ManagedSequence for some code that gets
badly bitten by this. However, aside from creating one or more
superclasses of Iterable that define the more functional interfaces,
it's hard to see how to improve.
> Here's something I threw together last night to try to address these
> problems. The basic principles are:
>
> - It should be easy to convert between collection types
Fair enough.
> - Consequently it's ok if we return the "wrong" thing.
Only if we assume that all our operations are non-strict, which I don't
think is a good thing.
> - In fact it may be desirable to do so!
> - All we care about generically are how to traverse a data structure
> and how to build one, so these are the operations the API should be
> designed around.
Clearly, but that is already the case.
> So the API defines a trait Enumerable which describes how to traverse
> a structure and a trait Buildable which describes how to build one
> (the data structure doesn't implement Buildable, one makes an implicit
> instance available). Implementations do not override the enumerable
> map, flatMap, etc. methods - these continue to return a generic
> enumerable. However at the end of a bunch of operations you explicitly
> "cast" to the desired result.
Do you have some type signatures for these classes that you can show us?
...
> We can use return from inside passed closures to control evaluation
> and exit the loop prematurely, which allows efficient implementation
> of things like exists, foreach and take. For example:
Non-local returns are implemented via exceptions, so they are not
really efficient. I think any move away from iterators is likely to
imply a performance loss.
/J
> So, with the recent noise I've been making about the collections API,
> I figured I should put some thoughts down on screen.
>
> As I see it one of the main problems with the current collection API
> is that in order to make things play nicely you need to override
> methods at every step of the way. map, filter, flatMap etc all return
> the "wrong" things. This is a pain to write and easy to get wrong.
This is what Martin is talking about fixing with type constructor
polymorphism, which seems preferable by far.
> The other thing I don't like about the collections API is that I'm not
> a big fan of iterators. They're really cumbersome to create for custom
> collection types and are designed around a really irritating "check
> then proceed" style. Really all we care about is how to traverse the
> data structure, and constructing an iterator to do so is often not the
> best way.
Agreed. See scalax.control.ManagedSequence for some code that gets
badly bitten by this. However, aside from creating one or more
superclasses of Iterable that define the more functional interfaces,
it's hard to see how to improve.
> Here's something I threw together last night to try to address these
> problems. The basic principles are:
>
> - It should be easy to convert between collection types
Fair enough.
> - Consequently it's ok if we return the "wrong" thing.
Only if we assume that all our operations are non-strict, which I don't
think is a good thing.
> - In fact it may be desirable to do so!
> - All we care about generically are how to traverse a data structure
> and how to build one, so these are the operations the API should be
> designed around.
Clearly, but that is already the case.
> So the API defines a trait Enumerable which describes how to traverse
> a structure and a trait Buildable which describes how to build one
> (the data structure doesn't implement Buildable, one makes an implicit
> instance available). Implementations do not override the enumerable
> map, flatMap, etc. methods - these continue to return a generic
> enumerable. However at the end of a bunch of operations you explicitly
> "cast" to the desired result.
Do you have some type signatures for these classes that you can show us?
...
> We can use return from inside passed closures to control evaluation
> and exit the loop prematurely, which allows efficient implementation
> of things like exists, foreach and take. For example:
Non-local returns are implemented via exceptions, so they are not
really efficient. I think any move away from iterators is likely to
imply a performance loss.
/J
« Return to Thread: Towards a revised collection API
| Free embeddable forum powered by Nabble | Forum Help |
