Naming collection operations

[John Nilsson]

including/excluding ?

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

[Jorge Ortiz-3]

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@...> wrote:

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.

[Nils Kilden-Pedersen]

On Mon, May 11, 2009 at 2:24 PM, Jorge Ortiz <jorge.ortiz@...> 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-2]

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@...> wrote:

On Mon, May 11, 2009 at 2:24 PM, Jorge Ortiz <jorge.ortiz@...> wrote: > > My understanding is ...

Then why wouldn't the clone methods work?

[Nils Kilden-Pedersen]

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.rudolph@...> 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@...> wrote:

On Mon, May 11, 2009 at 2:24 PM, Jorge Ortiz <jorge.ortiz@...> wrote: > > My understanding is ...

Then why wouldn't the clone methods work?

[Larry Yogman]

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

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

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

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

[Martin Odersky]

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

Thanks for your input!

 -- Martin


On Mon, May 11, 2009 at 10:24 PM, Meredith Gregory
<lgreg.meredith@...> wrote:

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

[David MacIver]

2009/5/11 martin odersky <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]

plus one

2009/5/12 David MacIver <david.maciver@...>

2009/5/11 martin odersky <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.

[Viktor Klang]

attach/detach ?

On Tue, May 12, 2009 at 12:04 PM, Ricky Clarkson <ricky.clarkson@...> wrote:

plus one

2009/5/12 David MacIver <david.maciver@...>

2009/5/11 martin odersky <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.

--
Viktor Klang
Senior Systems Analyst

[odd.moller]

Some parts of this message have been removed. Learn more about Nabble's security policy.

+1

 

Odd Möller
CTO Traveas.com
[phone]
odd@...

 

From: John Nilsson [mailto:john@...]
Sent: Monday, May 11, 2009 9:19 PM
To: martin odersky
Cc: Scala Debate; scala-internals@...
Subject: Re: [scala-internals] Naming collection operations

 

including/excluding ?

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

 

[Rob Dickens-2]

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

plus one

2009/5/12 David MacIver <david.maciver@...>

2009/5/11 martin odersky <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.

--
Rob, Lafros.com

[David MacIver]

2009/5/12 Rob Dickens <arctic.bob@...>:
> 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"

[Stepan Koltsov-5]

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 <david.maciver@...> wrote:

> 2009/5/11 martin odersky <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.

[Tony Morris-4]

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.

--
Tony Morris
http://tmorris.net/

[Paul Phillips-3]

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

--
Paul Phillips      | If this is raisin, make toast with it.
Caged Spirit       |
Empiricist         |
i pull his palp!   |----------* http://www.improving.org/paulp/ *----------

[Landei]

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

[Erik Engbrecht]

+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.maciver@...> wrote:

2009/5/12 Rob Dickens <arctic.bob@...>:

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

[David MacIver]

2009/5/12 Landei <Daniel.Gronau@...>:
>
> 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.