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

Naming collection operations

62 replies
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.

I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Naming collection operations
gain / lose ?

On Mon, May 11, 2009 at 10:18 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

Walter Chang
Joined: 2008-08-21,
User offline. Last seen 3 years 26 weeks ago.
Re: Naming collection operations
less / ssel ;-)

On Mon, May 11, 2009 at 4:35 PM, Viktor Klang <viktor [dot] klang [at] gmail [dot] com> wrote:
gain / lose ?

On Mon, May 11, 2009 at 10:18 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Naming collection operations
I'd like it to be an error, not a warning.  I know I personally have some deprecation warnings I ignore, because, for instance, I prefer writing List(1, 2) + 3 to List(1, 2) ++ List(3) (though I'm not writing that in any new code).  So I might not notice new ones, and I bet I'm not the only one.  Changing the meaning seems to require something stronger than deprecation, perhaps just deleting the method for a few versions.

2009/5/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Naming collection operations
I'd like it to be an error, not a warning.  I know I personally have some deprecation warnings I ignore, because, for instance, I prefer writing List(1, 2) + 3 to List(1, 2) ++ List(3) (though I'm not writing that in any new code).  So I might not notice new ones, and I bet I'm not the only one.  Changing the meaning seems to require something stronger than deprecation, perhaps just deleting the method for a few versions.

2009/5/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

Rob Dickens
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Naming collection operations
fadd, fremove
2009/5/11 Viktor Klang <viktor [dot] klang [at] gmail [dot] com>
gain / lose ?

On Mon, May 11, 2009 at 10:18 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Naming collection operations
At the risk of method overloading, I'd suggest union/minus

(Speaking of which... why is Set's minus called diff?)

--j

On Mon, May 11, 2009 at 1:18 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Naming collection operations
At the risk of method overloading, I'd suggest union/minus

(Speaking of which... why is Set's minus called diff?)

--j

On Mon, May 11, 2009 at 1:18 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

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:03 AM, Jorge Ortiz wrote:
> At the risk of method overloading, I'd suggest union/minus

union exists but it takes two sets (and could be extended to take two
maps). What I'm after is an operation that augments a set or map with
a single element/binding.

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:03 AM, Jorge Ortiz wrote:
> At the risk of method overloading, I'd suggest union/minus

union exists but it takes two sets (and could be extended to take two
maps). What I'm after is an operation that augments a set or map with
a single element/binding.

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:25 AM, martin odersky wrote:
> On Mon, May 11, 2009 at 11:03 AM, Jorge Ortiz 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:25 AM, martin odersky wrote:
> On Mon, May 11, 2009 at 11:03 AM, Jorge Ortiz 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

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: Naming collection operations
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

Tony Sloane
Joined: 2009-01-07,
User offline. Last seen 2 years 32 weeks ago.
Re: Naming collection operations

On 11/05/2009, at 6:18 PM, martin odersky wrote:

> I have a question concerning an alternative naming for the + and -
> methods on sets and maps.
> We need a good letter-based name for the purely functional version of
> these methods. `with` and `withOut` would have worked except that
> `with` is a reserved word.

How about withIn and withOut? Nice symmetry there...

Tony

Michael Wohlwend
Joined: 2009-03-12,
User offline. Last seen 3 years 29 weeks ago.
Re: Naming collection operations

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)

Michael

Rob Dickens
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations
plus/minus?

2009/5/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
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

Colin Bullock
Joined: 2009-01-23,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations


On Mon, May 11, 2009 at 4:59 AM, Rob Dickens <arctic [dot] bob [at] googlemail [dot] com> wrote:
plus/minus?


I'd also vote for plus/minus. Not only are they they actual names of the symbols, and hence easy to associate in one's mind, but they also seem to convey the right connotation (to me, at least) of adding (subtracting) two "values" and returning a third.

- Colin
Justin du coeur
Joined: 2009-03-04,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations
On Mon, May 11, 2009 at 5:59 AM, Rob Dickens <arctic [dot] bob [at] googlemail [dot] com> wrote:
plus/minus?

+1 -- it's the obvious naming that I would guess, if I had to ask myself "what would the verbal version of these symbols be?"

loverdos
Joined: 2008-11-18,
User offline. Last seen 2 years 27 weeks ago.
Re: Naming collection operations
newWith/newWithout ?

On Mon, May 11, 2009 at 11:18, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

loverdos
Joined: 2008-11-18,
User offline. Last seen 2 years 27 weeks ago.
Re: Naming collection operations
newWith/newWithout ?

On Mon, May 11, 2009 at 11:18, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

Johannes Rudolph
Joined: 2008-12-17,
User offline. Last seen 29 weeks 20 hours ago.
Re: Re: Naming collection operations

What about cum/sine?

On Mon, May 11, 2009 at 5:41 PM, Justin du coeur wrote:
> On Mon, May 11, 2009 at 5:59 AM, Rob Dickens
> wrote:
>>
>> plus/minus?
>
> +1 -- it's the obvious naming that I would guess, if I had to ask myself
> "what would the verbal version of these symbols be?"

Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: Re: Naming collection operations

On Monday May 11 2009, Johannes Rudolph wrote:
> What about cum/sine?

Hmm... Latin ain't what it used to be...

Why not "mit" and "ohne?" At least there are still plenty of people
speaking German.

RRS

sujaggu
Joined: 2009-05-08,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

These may be a bit confusing though. If plus works on an object, people may
be tempted to use + next time in it's place.

Justin du coeur wrote:
>
> On Mon, May 11, 2009 at 5:59 AM, Rob Dickens
> wrote:
>
>> plus/minus?
>
>
> +1 -- it's the obvious naming that I would guess, if I had to ask myself
> "what would the verbal version of these symbols be?"
>
>

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Naming collection operations
including/excluding ?

On Mon, May 11, 2009 at 10:18 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Naming collection operations
including/excluding ?

On Mon, May 11, 2009 at 10:18 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

Larry Yogman
Joined: 2009-05-11,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

+1 on plus/minus. If the names '+' and '-' are appropriate (and I think they
are, for purely functional operations), then so are 'plus' and 'minus'.

I personally wouldn't mind 'mit' und 'ohne', but I lived in Bundesrepublik
Deutschland for a couple of years.

Rob Dickens-2 wrote:
>
> plus/minus?
>
> 2009/5/11 martin odersky
>
>> On Mon, May 11, 2009 at 11:25 AM, martin odersky
>> wrote:
>> > On Mon, May 11, 2009 at 11:03 AM, Jorge Ortiz
>> 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
>>
>> -- Martin
>>
>
>

Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations
All,

plus/minus works for me as does the variant plus/sans .

Best wishes,

--greg

On Mon, May 11, 2009 at 12:52 PM, Larry Yogman <lyogman [at] pervasive [dot] com> wrote:

+1 on plus/minus.  If the names '+' and '-' are appropriate (and I think they
are, for purely functional operations), then so are 'plus' and 'minus'.

I personally wouldn't mind 'mit' und 'ohne', but I lived in Bundesrepublik
Deutschland for a couple of years.


Rob Dickens-2 wrote:
>
> plus/minus?
>
> 2009/5/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
>
>> 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
>>
>>  -- Martin
>>
>
>

--
View this message in context: http://www.nabble.com/Naming-collection-operations-tp23478942p23490294.html
Sent from the Scala - Debate mailing list archive at Nabble.com.




--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

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

It seems plus/minus has the relative majority of votes. Let's use that then.

Thanks for your input!

DRMacIver
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

2009/5/11 martin odersky :
> It seems plus/minus has the relative majority of votes. Let's use that then.

It's a bit late for me to get in this discussion now, but I was
avoiding it on the assumption that people would choose something
vaguely sensible and given that the details really didn't matter that
much. Unfortunately it seems people have settled on the single choice
which I find offensive, so time for me to whine. :-)

plus/minus seem like a *terrible* choice of name to me. First, it
completely defeats the point of choosing non symbolic names: Using
plus/minus vs +/- is totally arbitrary and inconsistent.

Further, using + (or, equivalently, plus) for non commutative
operators is a horrible convention. Using it for operators which it
doesn't even make sense to commute is even worse. It only makes even
the slightest bit of sense in languages which don't support decent
function naming and force you to pass everything symbolic through
overloading the standard arithmetic operators. Scala isn't one of
those languages (thankfully), so lets not inherit their mistakes.

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Re: Naming collection operations
plus one

2009/5/12 David MacIver <david [dot] maciver [at] gmail [dot] com>
2009/5/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>:
> It seems plus/minus has the relative majority of votes. Let's use that then.

It's a bit late for me to get in this discussion now, but I was
avoiding it on the assumption that people would choose something
vaguely sensible and given that the details really didn't matter that
much. Unfortunately it seems people have settled on the single choice
which I find offensive, so time for me to whine. :-)

plus/minus seem like a *terrible* choice of name to me. First, it
completely defeats the point of choosing non symbolic names: Using
plus/minus vs +/- is totally arbitrary and inconsistent.

Further, using + (or, equivalently, plus) for non commutative
operators is a horrible convention. Using it for operators which it
doesn't even make sense to commute is even worse. It only makes even
the slightest bit of sense in languages which don't support decent
function naming and force you to pass everything symbolic through
overloading the standard arithmetic operators. Scala isn't one of
those languages (thankfully), so lets not inherit their mistakes.

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: Naming collection operations
attach/detach ?

On Tue, May 12, 2009 at 12:04 PM, Ricky Clarkson <ricky [dot] clarkson [at] gmail [dot] com> wrote:
plus one

2009/5/12 David MacIver <david [dot] maciver [at] gmail [dot] com>
2009/5/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>:
> It seems plus/minus has the relative majority of votes. Let's use that then.

It's a bit late for me to get in this discussion now, but I was
avoiding it on the assumption that people would choose something
vaguely sensible and given that the details really didn't matter that
much. Unfortunately it seems people have settled on the single choice
which I find offensive, so time for me to whine. :-)

plus/minus seem like a *terrible* choice of name to me. First, it
completely defeats the point of choosing non symbolic names: Using
plus/minus vs +/- is totally arbitrary and inconsistent.

Further, using + (or, equivalently, plus) for non commutative
operators is a horrible convention. Using it for operators which it
doesn't even make sense to commute is even worse. It only makes even
the slightest bit of sense in languages which don't support decent
function naming and force you to pass everything symbolic through
overloading the standard arithmetic operators. Scala isn't one of
those languages (thankfully), so lets not inherit their mistakes.




--
Viktor Klang
Senior Systems Analyst
Rob Dickens
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations
minus 1
So should we do away with "string 1" + "string 2" as well then?
'totally arbitrary' it is not

2009/5/12 Ricky Clarkson <ricky [dot] clarkson [at] gmail [dot] com>
plus one

2009/5/12 David MacIver <david [dot] maciver [at] gmail [dot] com>
2009/5/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>:
> It seems plus/minus has the relative majority of votes. Let's use that then.

It's a bit late for me to get in this discussion now, but I was
avoiding it on the assumption that people would choose something
vaguely sensible and given that the details really didn't matter that
much. Unfortunately it seems people have settled on the single choice
which I find offensive, so time for me to whine. :-)

plus/minus seem like a *terrible* choice of name to me. First, it
completely defeats the point of choosing non symbolic names: Using
plus/minus vs +/- is totally arbitrary and inconsistent.

Further, using + (or, equivalently, plus) for non commutative
operators is a horrible convention. Using it for operators which it
doesn't even make sense to commute is even worse. It only makes even
the slightest bit of sense in languages which don't support decent
function naming and force you to pass everything symbolic through
overloading the standard arithmetic operators. Scala isn't one of
those languages (thankfully), so lets not inherit their mistakes.




--
Rob, Lafros.com
odd
Joined: 2009-04-07,
User offline. Last seen 26 weeks 4 days ago.
RE: Naming collection operations

+1

 

Odd Möller
CTO Traveas.com
+46 73 523 11 06
odd [at] traveas [dot] com

 

From: John Nilsson [mailto:john [at] milsson [dot] nu]
Sent: Monday, May 11, 2009 9:19 PM
To: martin odersky
Cc: Scala Debate; scala-internals [at] listes [dot] epfl [dot] ch
Subject: Re: [scala-internals] Naming collection operations

 

including/excluding ?

On Mon, May 11, 2009 at 10:18 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

 -- Martin

 

odd
Joined: 2009-04-07,
User offline. Last seen 26 weeks 4 days ago.
RE: Naming collection operations

+1

 

Odd Möller
CTO Traveas.com
+46 73 523 11 06
odd [at] traveas [dot] com

 

From: John Nilsson [mailto:john [at] milsson [dot] nu]
Sent: Monday, May 11, 2009 9:19 PM
To: martin odersky
Cc: Scala Debate; scala-internals [at] listes [dot] epfl [dot] ch
Subject: Re: [scala-internals] Naming collection operations

 

including/excluding ?

On Mon, May 11, 2009 at 10:18 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

I have a question concerning an alternative naming for the + and -
methods on sets and maps.
We need a good letter-based name for the purely functional version of
these methods. `with` and `withOut` would have worked except that
`with` is a reserved word.

There are basically two reasons why we need the alternate names. One
is callability from Java. The other is that we are moving away from a
design where + and - mean different things for different collections.
Currently, they are side-effecting for mutable collections and create
new ones for immutable collections. The idea is to use +=, -= for the
side-effecting versions of + and -, and to reserve + and - for
operations that always create a new collection. To help users migrate,
+ and - will stay side-effecting on mutable collections for the time
being but will be deprecated there. The deprecation comment will say,
if you want to keep the same meaning in the future, use +=,
respectively -=, but if you really want a new collection, then use
<insert name> here to make the deprecation warning go away.

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.

So, if you have a proposal, I'm interested!

Thanks

 -- Martin

 

Stepan Koltsov 2
Joined: 2009-01-21,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

I agree with David: + should sum elements of same type.

My opinion:

Do not add functional plus single element and minus single element
operations for a while (forcing user to write items ++ Seq(elem) ) for
a while.

Deprecate all def +, def -, def +=, def -= opertaions.

Since Scala 2.9:

def + to pure functional sum two collections.
def - to pure functional subtraction of second collection from first
def += like "addAll" in JDK
def -= like "removeAll" in JDK

Since Scala 2.10:

def ++ to add single element to the new collection
def -- to remove single element from the collection
def ++= to add single element to the collection and return unit ("add in JDK)
def --= "remove" in JDK

I remember, that Martin would like to have Seq[String]() + "x" to
yield string. With these proposals, result of that operation will be
Seq[Any] with single char inside (if String has type Seq[Char]).

Anyway, it's great that + will have no side-effect some day.

S.

On Tue, May 12, 2009 at 13:54, David MacIver wrote:
> 2009/5/11 martin odersky :
>> It seems plus/minus has the relative majority of votes. Let's use that then.
>
> It's a bit late for me to get in this discussion now, but I was
> avoiding it on the assumption that people would choose something
> vaguely sensible and given that the details really didn't matter that
> much. Unfortunately it seems people have settled on the single choice
> which I find offensive, so time for me to whine. :-)
>
> plus/minus seem like a *terrible* choice of name to me. First, it
> completely defeats the point of choosing non symbolic names: Using
> plus/minus vs +/- is totally arbitrary and inconsistent.
>
> Further, using + (or, equivalently, plus) for non commutative
> operators is a horrible convention. Using it for operators which it
> doesn't even make sense to commute is even worse. It only makes even
> the slightest bit of sense in languages which don't support decent
> function naming and force you to pass everything symbolic through
> overloading the standard arithmetic operators. Scala isn't one of
> those languages (thankfully), so lets not inherit their mistakes.

DRMacIver
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

2009/5/12 Rob Dickens :
> minus 1
> So should we do away with "string 1" + "string 2" as well then?

In an ideal world, absolutely 110%. + for String concatenation is
terrible on so many levels. It exists in Scala solely because it was
believed that Java people were too used to it to do without it. But
this battle is already lost,

> 'totally arbitrary' it is not

"precedent" is just another way of saying "those who are unable to
learn from history are doomed to repeat it"

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Naming collection operations

Stepan Koltsov wrote:
> I agree with David: + should sum elements of same type.
>
>
I think David was saying that + may work on many types, but it should
satisfy the commutativity property regardless of the type.
Hence the earlier objection to String.+ which is associative, but not
commutative.

I also agree that with regard to String.+ "this battle is lost" but
nonetheless any future "plus" should satisfy commutativity (history is a
learning opportunity). For what it is worth, Haskell's MonadPlus.mplus
doesn't necessarily satisfy commutativity (though it must for
associativity) and this has always bothered me, just a little.

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Re: Naming collection operations

Should the battle turn against plus and minus at the 11th hour, I
thought newWith and newWithout were the best.

Landei
Joined: 2008-12-18,
User offline. Last seen 45 weeks 4 days ago.
Re: Re: Naming collection operations

I'd vote for incl(uding)/excl(uding)

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: Re: Naming collection operations
+1

I think using + from string concatenation is an abomination (ok...that's a little melodramatic, but...)...
...that being said it is already in so many languages that it would confuse people to not have it.

On Tue, May 12, 2009 at 6:59 AM, David MacIver <david [dot] maciver [at] gmail [dot] com> wrote:
2009/5/12 Rob Dickens <arctic [dot] bob [at] googlemail [dot] com>:
> minus 1
> So should we do away with "string 1" + "string 2" as well then?

In an ideal world, absolutely 110%. + for String concatenation is
terrible on so many levels. It exists in Scala solely because it was
believed that Java people were too used to it to do without it. But
this battle is already lost,

> 'totally arbitrary' it is not

"precedent" is just another way of saying "those who are unable to
learn from history are doomed to repeat it"



--
http://erikengbrecht.blogspot.com/
DRMacIver
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

2009/5/12 Landei :
>
> I'd vote for incl(uding)/excl(uding)

For what it's worth, this is my favourite so far too. I don't have a
strong opinion other than "not plus/minus" though.

Johannes Rudolph
Joined: 2008-12-17,
User offline. Last seen 29 weeks 20 hours ago.
Re: Re: Naming collection operations

Since my attempt to attract more Vatican developers to Scala with
cum/sine found no enthusiasm, I would opt in for including/excluding
as well.

On Tue, May 12, 2009 at 2:07 PM, David MacIver wrote:
> 2009/5/12 Landei :
>>
>> I'd vote for incl(uding)/excl(uding)
>
> For what it's worth, this is my favourite so far too. I don't have a
> strong opinion other than "not plus/minus" though.

Larry Yogman
Joined: 2009-05-11,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

I share the misgivings about + to add one element to a collection, rather
than add collections of the same type. Ditto for + as a non-commutative
concatenation operator. If you start without C prejudices, then VB's choice
of & is actually a good one (gasp), particularly if there's a chance of
hidden conversion of numbers to strings. "1" + 1 == "11".

However, we're not working from a clean sheet of paper here, or trying to
achieve perfection. Scala is growing by attracting migrants from Java.
Some shared vocabulary really helps. Scala is better enough to attract
interest, and at the same time superficially familiar enough for gradual
self-retraining. I've been in self-retraining for the last couple years,
and am now trying to co-opt my all-Java-all-the-time coworkers. Having lots
of version-to-version change is bad for source bases, documentation, and the
community.

Using + to add one and ++ to add more than one is mnemonic. It's what Larry
Wall would do (gasp again), and he was doing quite well until he let
ambition trump incremental pragmatism with Perl 6.

Stepan Koltsov-5 wrote:
>
> I agree with David: + should sum elements of same type.
>
> My opinion:
>
> Do not add functional plus single element and minus single element
> operations for a while (forcing user to write items ++ Seq(elem) ) for
> a while.
>
> Deprecate all def +, def -, def +=, def -= opertaions.
>
> Since Scala 2.9:
>
> def + to pure functional sum two collections.
> def - to pure functional subtraction of second collection from first
> def += like "addAll" in JDK
> def -= like "removeAll" in JDK
>
> Since Scala 2.10:
>
> def ++ to add single element to the new collection
> def -- to remove single element from the collection
> def ++= to add single element to the collection and return unit ("add in
> JDK)
> def --= "remove" in JDK
>
> I remember, that Martin would like to have Seq[String]() + "x" to
> yield string. With these proposals, result of that operation will be
> Seq[Any] with single char inside (if String has type Seq[Char]).
>
>
> Anyway, it's great that + will have no side-effect some day.
>
> S.
>
>

DRMacIver
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

2009/5/12 Larry Yogman :
>
> I share the misgivings about + to add one element to a collection, rather
> than add collections of the same type.  Ditto for + as a non-commutative
> concatenation operator.  If you start without C prejudices, then VB's choice
> of & is actually a good one (gasp), particularly if there's a chance of
> hidden conversion of numbers to strings.  "1" + 1 == "11".
>
> However, we're not working from a clean sheet of paper here, or trying to
> achieve perfection.  Scala is growing by attracting migrants from Java.
> Some shared vocabulary really helps.  Scala is better enough to attract
> interest, and at the same time superficially familiar enough for gradual
> self-retraining.  I've been in self-retraining for the last couple years,
> and am now trying to co-opt my all-Java-all-the-time coworkers.  Having lots
> of version-to-version change is bad for source bases, documentation, and the
> community.

I don't see how this is relevant. it's not like the equivalent
operations even exist in Java, let alone like they're called
plus/minus.

We're talking about a one off change for a big collections redesign,
when the existing has a lot of known API problems. Getting it right
this one time is much more important than maintaining complete
compatibility.

No one (I hope) is suggesting the removal of + for String
concatenation. It's clearly not going to happen, even if some of us
would want it to. But if anything that makes the use of + (and I hope
my claim that calling it "plus" instead of "+" is completely
inconsistent and confusing is uncontroversial) *worse*, not better,
because it means that the meaning conflicts in a bunch of cases.

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Re: Naming collection operations
I like either "withTail" / "without" or "including" /"excluding"

+1 on obeying commutative properties for plus.   Unless of course it's being used as a  replacement for t, when writing in 133+


- Josh


On Tue, May 12, 2009 at 8:26 AM, Larry Yogman <lyogman [at] pervasive [dot] com> wrote:

I share the misgivings about + to add one element to a collection, rather
than add collections of the same type.  Ditto for + as a non-commutative
concatenation operator.  If you start without C prejudices, then VB's choice
of & is actually a good one (gasp), particularly if there's a chance of
hidden conversion of numbers to strings.  "1" + 1 == "11".

However, we're not working from a clean sheet of paper here, or trying to
achieve perfection.  Scala is growing by attracting migrants from Java.
Some shared vocabulary really helps.  Scala is better enough to attract
interest, and at the same time superficially familiar enough for gradual
self-retraining.  I've been in self-retraining for the last couple years,
and am now trying to co-opt my all-Java-all-the-time coworkers.  Having lots
of version-to-version change is bad for source bases, documentation, and the
community.

Using + to add one and ++ to add more than one is mnemonic.  It's what Larry
Wall would do (gasp again), and he was doing quite well until he let
ambition trump incremental pragmatism with Perl 6.


Stepan Koltsov-5 wrote:
>
> I agree with David: + should sum elements of same type.
>
> My opinion:
>
> Do not add functional plus single element and minus single element
> operations for a while (forcing user to write items ++ Seq(elem) ) for
> a while.
>
> Deprecate all def +, def -, def +=, def -= opertaions.
>
> Since Scala 2.9:
>
> def + to pure functional sum two collections.
> def - to pure functional subtraction of second collection from first
> def += like "addAll" in JDK
> def -= like "removeAll" in JDK
>
> Since Scala 2.10:
>
> def ++ to add single element to the new collection
> def -- to remove single element from the collection
> def ++= to add single element to the collection and return unit ("add in
> JDK)
> def --= "remove" in JDK
>
> I remember, that Martin would like to have   Seq[String]() + "x"   to
> yield string. With these proposals, result of that operation will be
> Seq[Any] with single char inside (if String has type Seq[Char]).
>
>
> Anyway, it's great that + will have no side-effect some day.
>
> S.
>
>

--
View this message in context: http://www.nabble.com/Naming-collection-operations-tp23478942p23501574.html
Sent from the Scala - Debate mailing list archive at Nabble.com.


Stepan Koltsov 2
Joined: 2009-01-21,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

On Tue, May 12, 2009 at 16:26, Larry Yogman wrote:
>
> Using + to add one and ++ to add more than one is mnemonic.

In this case, there is no need to add more "add" methods. Scala should
just change the behavior of + to make it pure functional, breaking
compatibility.

Compiler could warn, if the result of "+" on collection is not used.
One more annotation could be introduced -- @warnUnusedResult -- like
GCC function attribute warn_unused_result:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

Honestly, I doubt my original proposal will be accepted.

S.

> Stepan Koltsov-5 wrote:

I have too many e-mails...

>> I agree with David: + should sum elements of same type.
>>
>> My opinion:
>>
>> Do not add functional plus single element and minus single element
>> operations for a while (forcing user to write items ++ Seq(elem) ) for
>> a while.
>>
>> Deprecate all def +, def -, def +=, def -= opertaions.
>>
>> Since Scala 2.9:
>>
>> def + to pure functional sum two collections.
>> def - to pure functional subtraction of second collection from first
>> def += like "addAll" in JDK
>> def -= like "removeAll" in JDK
>>
>> Since Scala 2.10:
>>
>> def ++ to add single element to the new collection
>> def -- to remove single element from the collection
>> def ++= to add single element to the collection and return unit ("add in
>> JDK)
>> def --= "remove" in JDK
>>
>> I remember, that Martin would like to have   Seq[String]() + "x"   to
>> yield string. With these proposals, result of that operation will be
>> Seq[Any] with single char inside (if String has type Seq[Char]).
>>
>>
>> Anyway, it's great that + will have no side-effect some day.
>>
>> S.
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Naming-collection-operations-tp23478942p23501574.html
> Sent from the Scala - Debate mailing list archive at Nabble.com.
>
>

Stepan Koltsov 2
Joined: 2009-01-21,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

On Tue, May 12, 2009 at 16:34, David MacIver wrote:
> No one (I hope) is suggesting the removal of + for String
> concatenation.

Python string operator + accepts only strings as a parameter: "a" + 1
is a runtime error.

And sometimes it is desirable, for example, when you refactor method
return type from String to Option[String] you expect all method
invocations become compile time errors, to locate them and rewrite the
code. Having string.+(Option) not error, not all method invocation
sites get invalidated, so it is harder to refactor.

I'm not insisting string.+ for anything except string should be
removed, it is just not absolute good.

S.

Larry Yogman
Joined: 2009-05-11,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations

+1 Using include / includeAll and exclude / excludeAll for the purely
functional operations would be instantly understood by Java immigrants,
thanks to the influence of Ant and the add/addAll remove/removeAll pattern
in the Java collections library.

I withdraw my vote for plus and minus as the Java-callable names.

To push towards end-of-debate, may I suggest that the appropriateness of +
and ++ as operators probably belongs on a separate discussion thread, as
does the overlapping question of whether a String should behave as a
Seq[Char] without explicit conversion.

David MacIver wrote:
>
> 2009/5/12 Landei :
>>
>> I'd vote for incl(uding)/excl(uding)
>
> For what it's worth, this is my favourite so far too. I don't have a
> strong opinion other than "not plus/minus" though.
>
>

David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations


On Tue, May 12, 2009 at 2:54 AM, David MacIver <david [dot] maciver [at] gmail [dot] com> wrote:
2009/5/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>:
> It seems plus/minus has the relative majority of votes. Let's use that then.

It's a bit late for me to get in this discussion now, but I was
avoiding it on the assumption that people would choose something
vaguely sensible and given that the details really didn't matter that
much. Unfortunately it seems people have settled on the single choice
which I find offensive, so time for me to whine. :-)

plus/minus seem like a *terrible* choice of name to me. First, it
completely defeats the point of choosing non symbolic names: Using
plus/minus vs +/- is totally arbitrary and inconsistent.

I agree with David.
I would opt for add/remove.  I'm putting on my lawyer hat (and removing my terrible naming hat, which I wear most of the time).  The operations in question result in a new collection or operate on the existing collection and add or remove one or more elements from the original collection.  I believe the '+' operator has its roots in the concept of "adding" to a collection. 
My 2 cents.


Further, using + (or, equivalently, plus) for non commutative
operators is a horrible convention. Using it for operators which it
doesn't even make sense to commute is even worse. It only makes even
the slightest bit of sense in languages which don't support decent
function naming and force you to pass everything symbolic through
overloading the standard arithmetic operators. Scala isn't one of
those languages (thankfully), so lets not inherit their mistakes.



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Carsten Saager
Joined: 2008-12-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations
plus/minus "reads" as +/-

On Tue, May 12, 2009 at 12:47 PM, Viktor Klang <viktor [dot] klang [at] gmail [dot] com> wrote:
attach/detach ?
This seems to be used in a different context already

What about

adjoin/(without|seclude)

-Carsten
 


On Tue, May 12, 2009 at 12:04 PM, Ricky Clarkson <ricky [dot] clarkson [at] gmail [dot] com> wrote:
plus one

2009/5/12 David MacIver <david [dot] maciver [at] gmail [dot] com>
2009/5/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>:
> It seems plus/minus has the relative majority of votes. Let's use that then.

It's a bit late for me to get in this discussion now, but I was
avoiding it on the assumption that people would choose something
vaguely sensible and given that the details really didn't matter that
much. Unfortunately it seems people have settled on the single choice
which I find offensive, so time for me to whine. :-)

plus/minus seem like a *terrible* choice of name to me. First, it
completely defeats the point of choosing non symbolic names: Using
plus/minus vs +/- is totally arbitrary and inconsistent.

Further, using + (or, equivalently, plus) for non commutative
operators is a horrible convention. Using it for operators which it
doesn't even make sense to commute is even worse. It only makes even
the slightest bit of sense in languages which don't support decent
function naming and force you to pass everything symbolic through
overloading the standard arithmetic operators. Scala isn't one of
those languages (thankfully), so lets not inherit their mistakes.




--
Viktor Klang
Senior Systems Analyst

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