This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: Re: Naming collection operations

9 replies
Rob Dickens
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
including/excluding
or incl/excl

2009/5/11 Viktor Klang <viktor [dot] klang [at] gmail [dot] com>
inject / reject ?

On Mon, May 11, 2009 at 11:31 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
On Mon, May 11, 2009 at 11:25 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
> On Mon, May 11, 2009 at 11:03 AM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote:
>> At the risk of method overloading, I'd suggest union/minus
>
... and I really want to avoid method overloading for generic
collections; in conjunction with type inference it is more dangerous
than might seem at first. E.g. how do you resolve this:

val s: Set[Set[String]] = Set.empty

s union empty // is this Set.empty or Set(Set.empty) ?

Cheers

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Naming collection operations

On Mon, May 11, 2009 at 11:58 AM, Michael wrote:
> Am Monday 11 May 2009 10:18:13 schrieb martin odersky:
>
>> Therefore, one desiderata for the letter-based names is that they make
>> it clear that a new collection is created and the old collection is
>> left as it is. That's why I hesitate to use `add`, `remove`, for
>> example.
>>
>
> If you want to indicate that a new map/set is generated I don't think you can
> avoid using "clone" "new" or something similar in the name.
> So maybe  cloneWith (or cloneAdd) newWith copyWith (and Without or Minus for
> the other case)
>
The point is that this operation needs to work uniformly on mutable
and immutable collections. Cloning makes only sense of for the former.

Cheers

nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: Naming collection operations
On Mon, May 11, 2009 at 5:03 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
On Mon, May 11, 2009 at 11:58 AM, Michael <micha-1 [at] fantasymail [dot] de> wrote:
> Am Monday 11 May 2009 10:18:13 schrieb martin odersky:
>
>> Therefore, one desiderata for the letter-based names is that they make
>> it clear that a new collection is created and the old collection is
>> left as it is. That's why I hesitate to use `add`, `remove`, for
>> example.
>>
>
> If you want to indicate that a new map/set is generated I don't think you can
> avoid using "clone" "new" or something similar in the name.
> So maybe  cloneWith (or cloneAdd) newWith copyWith (and Without or Minus for
> the other case)
>
The point is that this operation needs to work uniformly on mutable
and immutable collections. Cloning makes only sense of for the former.

I'm a bit confused here, and it seems Michael is too.

Martin, do you want the names to makes sense for both mutable and immutable collections? That's what your last statement seems to indicate. Yet that's not what your original email implied, hence your hesitation for using add/remove.

Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Re: Naming collection operations
My understanding is that these methods would be available for both mutable and immutable collections, but that in both cases they would return a -new- collection with the elements added. That is, the methods won't actually mutate the mutable collection on which they're called. They'll create a new mutable collection with all the previous elements plus the additional element. The names "add" and "remove" seem to imply that the original collection will be mutated.

--j

On Mon, May 11, 2009 at 11:22 AM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
On Mon, May 11, 2009 at 5:03 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
On Mon, May 11, 2009 at 11:58 AM, Michael <micha-1 [at] fantasymail [dot] de> wrote:
> Am Monday 11 May 2009 10:18:13 schrieb martin odersky:
>
>> Therefore, one desiderata for the letter-based names is that they make
>> it clear that a new collection is created and the old collection is
>> left as it is. That's why I hesitate to use `add`, `remove`, for
>> example.
>>
>
> If you want to indicate that a new map/set is generated I don't think you can
> avoid using "clone" "new" or something similar in the name.
> So maybe  cloneWith (or cloneAdd) newWith copyWith (and Without or Minus for
> the other case)
>
The point is that this operation needs to work uniformly on mutable
and immutable collections. Cloning makes only sense of for the former.

I'm a bit confused here, and it seems Michael is too.

Martin, do you want the names to makes sense for both mutable and immutable collections? That's what your last statement seems to indicate. Yet that's not what your original email implied, hence your hesitation for using add/remove.


Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Re: Naming collection operations
My understanding is that these methods would be available for both mutable and immutable collections, but that in both cases they would return a -new- collection with the elements added. That is, the methods won't actually mutate the mutable collection on which they're called. They'll create a new mutable collection with all the previous elements plus the additional element. The names "add" and "remove" seem to imply that the original collection will be mutated.

--j

On Mon, May 11, 2009 at 11:22 AM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
On Mon, May 11, 2009 at 5:03 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
On Mon, May 11, 2009 at 11:58 AM, Michael <micha-1 [at] fantasymail [dot] de> wrote:
> Am Monday 11 May 2009 10:18:13 schrieb martin odersky:
>
>> Therefore, one desiderata for the letter-based names is that they make
>> it clear that a new collection is created and the old collection is
>> left as it is. That's why I hesitate to use `add`, `remove`, for
>> example.
>>
>
> If you want to indicate that a new map/set is generated I don't think you can
> avoid using "clone" "new" or something similar in the name.
> So maybe  cloneWith (or cloneAdd) newWith copyWith (and Without or Minus for
> the other case)
>
The point is that this operation needs to work uniformly on mutable
and immutable collections. Cloning makes only sense of for the former.

I'm a bit confused here, and it seems Michael is too.

Martin, do you want the names to makes sense for both mutable and immutable collections? That's what your last statement seems to indicate. Yet that's not what your original email implied, hence your hesitation for using add/remove.


nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: Naming collection operations
On Mon, May 11, 2009 at 2:24 PM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote:
My understanding is that these methods would be available for both mutable and immutable collections, but that in both cases they would return a -new- collection with the elements added. That is, the methods won't actually mutate the mutable collection on which they're called. They'll create a new mutable collection with all the previous elements plus the additional element. The names "add" and "remove" seem to imply that the original collection will be mutated.

Then why wouldn't the clone methods work?
nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: Naming collection operations
I probably misunderstood Martin's response. I was under the impression that he didn't want any of the proposals given (newWith, copyWith), but I see that his response only mentioned cloneWith.

On Mon, May 11, 2009 at 2:40 PM, Johannes Rudolph <johannes [dot] rudolph [at] googlemail [dot] com> wrote:

Because adding an element to an immutable collection doesn't clone the collection but makes a new object which references the old collection instead.

On May 11, 2009 9:30 PM, "Nils Kilden-Pedersen" <nilskp [at] gmail [dot] com> wrote:

On Mon, May 11, 2009 at 2:24 PM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote: > > My understanding is ...

Then why wouldn't the clone methods work?

nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: Naming collection operations
On Mon, May 11, 2009 at 2:24 PM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote:
My understanding is that these methods would be available for both mutable and immutable collections, but that in both cases they would return a -new- collection with the elements added. That is, the methods won't actually mutate the mutable collection on which they're called. They'll create a new mutable collection with all the previous elements plus the additional element. The names "add" and "remove" seem to imply that the original collection will be mutated.

Then why wouldn't the clone methods work?
Johannes Rudolph
Joined: 2008-12-17,
User offline. Last seen 29 weeks 20 hours ago.
Re: Re: Naming collection operations

Because adding an element to an immutable collection doesn't clone the collection but makes a new object which references the old collection instead.

On May 11, 2009 9:30 PM, "Nils Kilden-Pedersen" <nilskp [at] gmail [dot] com> wrote:

On Mon, May 11, 2009 at 2:24 PM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote: > > My understanding is ...

Then why wouldn't the clone methods work?

nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: Naming collection operations
I probably misunderstood Martin's response. I was under the impression that he didn't want any of the proposals given (newWith, copyWith), but I see that his response only mentioned cloneWith.

On Mon, May 11, 2009 at 2:40 PM, Johannes Rudolph <johannes [dot] rudolph [at] googlemail [dot] com> wrote:

Because adding an element to an immutable collection doesn't clone the collection but makes a new object which references the old collection instead.

On May 11, 2009 9:30 PM, "Nils Kilden-Pedersen" <nilskp [at] gmail [dot] com> wrote:

On Mon, May 11, 2009 at 2:24 PM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote: > > My understanding is ...

Then why wouldn't the clone methods work?

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland