why scala.collection.mutable.ArrayBuffer reverse return a new arraybuffer ?!

Methods that are in common between immutable and mutable collections obey the same contract for both.  In particular, this means that methods that create things for immutable collections must also create things for mutable collections.

This leaves mutable collections somewhat hampered in their in-place capability, since they have very few extra methods.  The most important one is transform (the in-place equivalent to map).

Be aware also that the update method will modify an element (normally used in shortcut form as a(i) = 7 rather than a.update(i,7)), while the updated method will return a copy with that element changed.  So if you're spelling it out rather than using the assignment shortcut, make sure you use the variant you want (probably update!).

  --Rex

On Tue, Dec 27, 2011 at 7:26 PM, wm <mingwu@gmail.com> wrote:

http://www.scala-lang.org/api/current/scala/collection/mutable/ArrayBuffer.html

Since it's mutable, shouldn't the reasonable implementation be
reversing in place.

On Dec 27, 4:41 pm, Rex Kerr wrote:
> Methods that are in common between immutable and mutable collections obey
> the same contract for both.  In particular, this means that methods that
> create things for immutable collections must also create things for mutable
> collections.
>
> This leaves mutable collections somewhat hampered in their in-place
> capability, since they have very few extra methods.  The most important one
> is transform (the in-place equivalent to map).

Then how about add extra mutable version of the method, named as e.g.
mutableReverse (at lease give this api option to the user).

There are lots of mutable methods that one might want copies of; I'm not sure how high of a priority this is.  Just off the top of my head, I'd like mutable versions of reverse and collect (partial transform) for all mutable collections; filter, drop, and take for shrinkable collections; and possibly more (e.g. flatMap in place).

  --Rex

On Tue, Dec 27, 2011 at 7:50 PM, wm <mingwu@gmail.com> wrote:

On Dec 27, 4:41 pm, Rex Kerr <icho...@gmail.com> wrote:
> Methods that are in common between immutable and mutable collections obey
> the same contract for both.  In particular, this means that methods that
> create things for immutable collections must also create things for mutable
> collections.
>
> This leaves mutable collections somewhat hampered in their in-place
> capability, since they have very few extra methods.  The most important one
> is transform (the in-place equivalent to map).

Then how about add extra mutable version of the method, named as e.g.
mutableReverse (at lease give this api option to the user).

sounds like an easy thing to do. i already needed this for buffers so i "enriched ma library" as you put it.

since i have some free days soon, i can implement a few prototypes for buffers, arrays, sets and maps. most methods should be straightforward to implement.

if it works out, how can we sneak that into the next scala release?

-------- Original-Nachricht --------
> Datum: Wed, 28 Dec 2011 04:03:03 -0500
> Von: Rex Kerr
> An: wm
> CC: scala-user
> Betreff: Re: [scala-user] Re: why scala.collection.mutable.ArrayBuffer reverse return a new arraybuffer ?!

> There are lots of mutable methods that one might want copies of; I'm not
> sure how high of a priority this is. Just off the top of my head, I'd
> like
> mutable versions of reverse and collect (partial transform) for all
> mutable
> collections; filter, drop, and take for shrinkable collections; and
> possibly more (e.g. flatMap in place).
>
> --Rex
>
> On Tue, Dec 27, 2011 at 7:50 PM, wm wrote:
>
> > On Dec 27, 4:41 pm, Rex Kerr wrote:
> > > Methods that are in common between immutable and mutable collections
> obey
> > > the same contract for both. In particular, this means that methods
> that
> > > create things for immutable collections must also create things for
> > mutable
> > > collections.
> > >
> > > This leaves mutable collections somewhat hampered in their in-place
> > > capability, since they have very few extra methods. The most
> important
> > one
> > > is transform (the in-place equivalent to map).
> >
> > Then how about add extra mutable version of the method, named as e.g.
> > mutableReverse (at lease give this api option to the user).

It would be cool to have these methods on the mutable collections.
How should these be named people don't drop dead when looking at the
scaladoc?

Peace. Michael

On Wed, Dec 28, 2011 at 1:54 AM, Dennis Haupt wrote:
> sounds like an easy thing to do. i already needed this for buffers so i "enriched ma library" as you put it.
>
> since i have some free days soon, i can implement a few prototypes for buffers, arrays, sets and maps. most methods should be straightforward to implement.
>
> if it works out, how can we sneak that into the next scala release?
>
> -------- Original-Nachricht --------
>> Datum: Wed, 28 Dec 2011 04:03:03 -0500
>> Von: Rex Kerr
>> An: wm
>> CC: scala-user
>> Betreff: Re: [scala-user] Re: why scala.collection.mutable.ArrayBuffer reverse return a new arraybuffer ?!
>
>> There are lots of mutable methods that one might want copies of; I'm not
>> sure how high of a priority this is.  Just off the top of my head, I'd
>> like
>> mutable versions of reverse and collect (partial transform) for all
>> mutable
>> collections; filter, drop, and take for shrinkable collections; and
>> possibly more (e.g. flatMap in place).
>>
>>   --Rex
>>
>> On Tue, Dec 27, 2011 at 7:50 PM, wm wrote:
>>
>> > On Dec 27, 4:41 pm, Rex Kerr wrote:
>> > > Methods that are in common between immutable and mutable collections
>> obey
>> > > the same contract for both.  In particular, this means that methods
>> that
>> > > create things for immutable collections must also create things for
>> > mutable
>> > > collections.
>> > >
>> > > This leaves mutable collections somewhat hampered in their in-place
>> > > capability, since they have very few extra methods.  The most
>> important
>> > one
>> > > is transform (the in-place equivalent to map).
>> >
>> > Then how about add extra mutable version of the method, named as e.g.
>> > mutableReverse (at lease give this api option to the user).

Why dont go to scalaz like library, I mean, not necessarily a part of the release ?
I wonder if  there is anything like clojure.contrib or javax -like for scala.
On Wed, Dec 28, 2011 at 10:54 AM, Dennis Haupt <h-star@gmx.de> wrote:

sounds like an easy thing to do. i already needed this for buffers so i "enriched ma library" as you put it.

since i have some free days soon, i can implement a few prototypes for buffers, arrays, sets and maps. most methods should be straightforward to implement.

if it works out, how can we sneak that into the next scala release?

-------- Original-Nachricht --------
> Datum: Wed, 28 Dec 2011 04:03:03 -0500
> Von: Rex Kerr <ichoran@gmail.com>
> An: wm <mingwu@gmail.com>
> CC: scala-user <scala-user@googlegroups.com>
> Betreff: Re: [scala-user] Re: why scala.collection.mutable.ArrayBuffer reverse return a new arraybuffer ?!

> There are lots of mutable methods that one might want copies of; I'm not
> sure how high of a priority this is.  Just off the top of my head, I'd
> like
> mutable versions of reverse and collect (partial transform) for all
> mutable
> collections; filter, drop, and take for shrinkable collections; and
> possibly more (e.g. flatMap in place).
>
>   --Rex
>
> On Tue, Dec 27, 2011 at 7:50 PM, wm <mingwu@gmail.com> wrote:
>
> > On Dec 27, 4:41 pm, Rex Kerr <icho...@gmail.com> wrote:
> > > Methods that are in common between immutable and mutable collections
> obey
> > > the same contract for both.  In particular, this means that methods
> that
> > > create things for immutable collections must also create things for
> > mutable
> > > collections.
> > >
> > > This leaves mutable collections somewhat hampered in their in-place
> > > capability, since they have very few extra methods.  The most
> important
> > one
> > > is transform (the in-place equivalent to map).
> >
> > Then how about add extra mutable version of the method, named as e.g.
> > mutableReverse (at lease give this api option to the user).