Naming collection operations

[Martin Odersky]

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

[Viktor Klang]

gain / lose ?

On Mon, May 11, 2009 at 10:18 AM, martin odersky <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.

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

--
Viktor Klang
Senior Systems Analyst

[Walter Chang]

less / ssel ;-)

On Mon, May 11, 2009 at 4:35 PM, Viktor Klang <viktor.klang@...> wrote:

gain / lose ?

On Mon, May 11, 2009 at 10:18 AM, martin odersky <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.

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

--
Viktor Klang
Senior Systems Analyst

--
.......__o
.......\<,
....( )/ ( )...

[Rob Dickens-2]

fadd, fremove

2009/5/11 Viktor Klang <viktor.klang@...>

gain / lose ?

On Mon, May 11, 2009 at 10:18 AM, martin odersky <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.

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

--
Viktor Klang
Senior Systems Analyst

--
Rob, Lafros.com

[Ricky Clarkson]

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.odersky@...>

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

[Jorge Ortiz-3]

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.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.

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

[Martin Odersky]

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

 -- Martin

>
> (Speaking of which... why is Set's minus called diff?)
>
Set difference. I think it's called that way in the Haskell libraries
but I might be wrong.

Cheers

 -- Martin

[Martin Odersky]

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

[Viktor Klang]

inject / reject ?

On Mon, May 11, 2009 at 11:31 AM, martin odersky <martin.odersky@...> wrote:

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

--
Viktor Klang
Senior Systems Analyst

[Rob Dickens-2]

including/excluding

or incl/excl

2009/5/11 Viktor Klang <viktor.klang@...>

inject / reject ?

On Mon, May 11, 2009 at 11:31 AM, martin odersky <martin.odersky@...> wrote:

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

--

Viktor Klang
Senior Systems Analyst

[Tony Sloane]

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

[Rob Dickens-2]

plus/minus?

2009/5/11 martin odersky <martin.odersky@...>

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

[Martin Odersky]

On Mon, May 11, 2009 at 11:58 AM, Michael <micha-1@...> 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

 -- Martin

[Colin Bullock]

On Mon, May 11, 2009 at 4:59 AM, Rob Dickens <arctic.bob@...> 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]

On Mon, May 11, 2009 at 5:59 AM, Rob Dickens <arctic.bob@...> 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?"

[Christos KK Loverdos]

newWith/newWithout ?

On Mon, May 11, 2009 at 11:18, martin odersky <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.

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

--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

[Johannes Rudolph-2]

What about cum/sine?

On Mon, May 11, 2009 at 5:41 PM, Justin du coeur <jducoeur@...> wrote:
> On Mon, May 11, 2009 at 5:59 AM, Rob Dickens <arctic.bob@...>
> 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?"

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[Randall Schulz]

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]

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 <[e-mail]>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?"

[Nils Kilden-Pedersen]

On Mon, May 11, 2009 at 5:03 AM, martin odersky <martin.odersky@...> wrote:

On Mon, May 11, 2009 at 11:58 AM, Michael <micha-1@...> 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.