« 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 13:28:48 David MacIver wrote:
> On Fri, Apr 18, 2008 at 1:13 PM, Jamie Webb <j@...>
> wrote:
> > 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.
>
> Sure. This solution uses type constructor polymorphism too. But
> getting it to handle returning the right type automatically without
> having to constantly reimplement isn't totally trivial.
The collections hierarchy is such a core part of the library that I
don't consider the implementation cost to be anywhere near as important
as usability or performance. From what I can see, your proposal falls
down on both those fronts.
> > > 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.
>
> Either the mailing list stripped the attached file, or you missed it.
> In the case that it's the former, here's a pastebin:
> http://pastebin.com/m23106284
Sorry, I missed it.
> My point is you can reimplement basically the entire Iterable trait
> sans "elements" based on only foreach.
You can, and I think it would be good to have a superclass of Iterable
that does this. However, below that there need to be classes which
implement these methods in a way that best suits their access
characteristics. The primary example of this at present is
RandomAccessSeq, but the same is true of all the variations to some
degree.
> > > - 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.
>
> I think this is ok. The useage I have in mind is that you do a bunch
> of calculations with a "suspended" result and then immediately thunk
> the whole thing.
So I'd have to write things like this?
myNumbers.map(_ * 2).as[List, Int]
That's... ugly.
> I'm not saying this will never be slower. But equally I expect there
> are a lot of times where it will be faster, particularly when it can
> eliminate a bunch of intermediate structures.
Bear in mind that the library already offers Projections which do this,
so your version will not be faster.
It seems like your Enumerable and Buildable concepts are perfectly
valuable things to have as part of the library, but there's no way you
could use them as the basis for a practical collections hierarchy. The
same is likely true of any other simple solution. The problem is not
simple.
I think the collections library needs tidying up and rationalising,
and updating to make use of current language features. I'd like to see
it /support/ collections that lack iterators. But I don't see the basic
design changing much.
/J
> On Fri, Apr 18, 2008 at 1:13 PM, Jamie Webb <j@...>
> wrote:
> > 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.
>
> Sure. This solution uses type constructor polymorphism too. But
> getting it to handle returning the right type automatically without
> having to constantly reimplement isn't totally trivial.
The collections hierarchy is such a core part of the library that I
don't consider the implementation cost to be anywhere near as important
as usability or performance. From what I can see, your proposal falls
down on both those fronts.
> > > 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.
>
> Either the mailing list stripped the attached file, or you missed it.
> In the case that it's the former, here's a pastebin:
> http://pastebin.com/m23106284
Sorry, I missed it.
> My point is you can reimplement basically the entire Iterable trait
> sans "elements" based on only foreach.
You can, and I think it would be good to have a superclass of Iterable
that does this. However, below that there need to be classes which
implement these methods in a way that best suits their access
characteristics. The primary example of this at present is
RandomAccessSeq, but the same is true of all the variations to some
degree.
> > > - 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.
>
> I think this is ok. The useage I have in mind is that you do a bunch
> of calculations with a "suspended" result and then immediately thunk
> the whole thing.
So I'd have to write things like this?
myNumbers.map(_ * 2).as[List, Int]
That's... ugly.
> I'm not saying this will never be slower. But equally I expect there
> are a lot of times where it will be faster, particularly when it can
> eliminate a bunch of intermediate structures.
Bear in mind that the library already offers Projections which do this,
so your version will not be faster.
It seems like your Enumerable and Buildable concepts are perfectly
valuable things to have as part of the library, but there's no way you
could use them as the basis for a practical collections hierarchy. The
same is likely true of any other simple solution. The problem is not
simple.
I think the collections library needs tidying up and rationalising,
and updating to make use of current language features. I'd like to see
it /support/ collections that lack iterators. But I don't see the basic
design changing much.
/J
« Return to Thread: Towards a revised collection API
| Free embeddable forum powered by Nabble | Forum Help |
