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

Naming collection operations

62 replies
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: Naming collection operations


On Tue, May 12, 2009 at 3:31 PM, Carsten Saager <csaager [at] gmail [dot] com> wrote:
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)

joinWith/partWith?

glue/unglue?

and/not ?
 


-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




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

Viktor Klang wrote:
>
>
>
> joinWith/partWith?
>
> glue/unglue?
>
> and/not ?
>

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

Ok, seeing as we're pulling words out of hats now; con/sin. Or even
con/sans. Con is from Spanish, everyone knows it from chilli con
carne (or chili con carne to los estadounidenses). Sans is from
French, everyone knows it from Comic Sans Serif, which I've always
assumed was a copy of the Beano without a sheriff in it.

List(1, 2) -:- 3

2009/5/12 Viktor Klang :
>
>
> On Tue, May 12, 2009 at 3:31 PM, Carsten Saager wrote:
>>
>> plus/minus "reads" as +/-
>>
>> On Tue, May 12, 2009 at 12:47 PM, Viktor Klang
>> wrote:
>>>
>>> attach/detach ?
>>
>> This seems to be used in a different context already
>>
>> What about
>>
>> adjoin/(without|seclude)
>
> joinWith/partWith?
>
> glue/unglue?
>
> and/not ?
>
>>
>> -Carsten
>>
>>>
>>>
>>> On Tue, May 12, 2009 at 12:04 PM, Ricky Clarkson
>>> wrote:
>>>>
>>>> plus one
>>>>
>>>> 2009/5/12 David MacIver
>>>>>
>>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> Viktor Klang
>>> Senior Systems Analyst
>>
>
>
>
> --
> Viktor Klang
> Senior Systems Analyst
>

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


On Tue, May 12, 2009 at 3:52 PM, Landei <Daniel [dot] Gronau [at] gmx [dot] de> wrote:



Viktor Klang wrote:
>
>
>
> joinWith/partWith?
>
> glue/unglue?
>
> and/not ?
>
> --
> Viktor Klang
> Senior Systems Analyst
>
>

shoveInto/yankOut ?

+1
 

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




--
Viktor Klang
Senior Systems Analyst
Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Re: Naming collection operations
I disagree on add/remove.

Those names are used in Java collections to mean the operation that mutates the underlying collection. Meaning anything else in Scala seems like a bad idea.

I like Ricky's suggestion of con/sin or (I'd go for consistency) avec/sans. If the names would have been with/without (save for 'with' being a keyword), then con/sin and avec/sans seem like logical choices. Unfortunately, I think the "programming should be in English only" backlash would be a bit fierce.

I like incl/excl. The only problem is they're already used in Sets and Maps, to mean mutate-and-return-unit in mutable collections and add-and-return-new-collection in immutable collections. That said, they're deprecated (how long have they been deprecated?) so maybe now is as good a time to break them as any.

One thing I'm confused about is the backlash against +/-. I didn't realize their meaning was up for discussion. Martin asked for suggestions for non-symbolic method names. Are people suggesting we break these too?

--j

On Tue, May 12, 2009 at 6:16 AM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:


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

Justin du coeur
Joined: 2009-03-04,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations
On Tue, May 12, 2009 at 5:54 AM, David MacIver <david [dot] maciver [at] gmail [dot] com> wrote:
Further, using + (or, equivalently, plus) for non commutative
operators is a horrible convention.

I can see that argument.  Mostly, I care about intuitive consistency here: my understanding was that we were looking for non-symbolic equivalents of + and -, but were leaving the symbolic versions *as well*.  (Am I correct here?)  That being the case, I strongly prefer "plus" and "minus", as the obvious verbal equivalents -- it matches the general Scala approach that guessing the answer tends to be right.  If we're willing to deprecate the symbols, though, that argument goes away.

So the heart of the question is: are we interested in deprecating and replacing + and - in cases where they don't match the mathematical formalisms?  If so, then choosing something entirely different for the verbal name makes sense.

We should keep in mind that this appears to matter a lot more to the mathematicians and formalists in the audience than to the down-and-dirty engineers -- honestly, it hadn't even occurred to me to care.  (I suspect that there's a strong correlation between this and whether folks come from functional vs. OO backgrounds, but that's just a guess.)  But given that the functional side of the audience does seem to care passionately, and I certainly don't, I'm willing to recant my opinion so long as we come up with some intuitively consistent approach...
Walter Chang
Joined: 2008-08-21,
User offline. Last seen 3 years 26 weeks ago.
Re: Re: Naming collection operations
+1 for incl/excl

On Tue, May 12, 2009 at 7:32 PM, Landei <Daniel [dot] Gronau [at] gmx [dot] de> wrote:

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

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




--
.......__o
.......\<,
....( )/ ( )...
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 7:26 AM, Jorge Ortiz <jorge [dot] ortiz [at] gmail [dot] com> wrote:
I disagree on add/remove.

Those names are used in Java collections to mean the operation that mutates the underlying collection. Meaning anything else in Scala seems like a bad idea.

I like Ricky's suggestion of con/sin or (I'd go for consistency) avec/sans. If the names would have been with/without (save for 'with' being a keyword), then con/sin and avec/sans seem like logical choices. Unfortunately, I think the "programming should be in English only" backlash would be a bit fierce.

I'm cool with con/sin or avec/sans with a minor preference for the latter.
oh... and my other car is a cdr 


I like incl/excl. The only problem is they're already used in Sets and Maps, to mean mutate-and-return-unit in mutable collections and add-and-return-new-collection in immutable collections. That said, they're deprecated (how long have they been deprecated?) so maybe now is as good a time to break them as any.

One thing I'm confused about is the backlash against +/-. I didn't realize their meaning was up for discussion. Martin asked for suggestions for non-symbolic method names. Are people suggesting we break these too?

--j

On Tue, May 12, 2009 at 6:16 AM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:


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




--
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
Rob Dickens
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Naming collection operations
> So the heart of the question is: are we interested in deprecating and replacing + and - ...
I agree: only go with plus/minus if we're going to keep +/-.

2009/5/12 Justin du coeur <jducoeur [at] gmail [dot] com>
On Tue, May 12, 2009 at 5:54 AM, David MacIver <david [dot] maciver [at] gmail [dot] com> wrote:
Further, using + (or, equivalently, plus) for non commutative
operators is a horrible convention.

I can see that argument.  Mostly, I care about intuitive consistency here: my understanding was that we were looking for non-symbolic equivalents of + and -, but were leaving the symbolic versions *as well*.  (Am I correct here?)  That being the case, I strongly prefer "plus" and "minus", as the obvious verbal equivalents -- it matches the general Scala approach that guessing the answer tends to be right.  If we're willing to deprecate the symbols, though, that argument goes away.

So the heart of the question is: are we interested in deprecating and replacing + and - in cases where they don't match the mathematical formalisms?  If so, then choosing something entirely different for the verbal name makes sense.

We should keep in mind that this appears to matter a lot more to the mathematicians and formalists in the audience than to the down-and-dirty engineers -- honestly, it hadn't even occurred to me to care.  (I suspect that there's a strong correlation between this and whether folks come from functional vs. OO backgrounds, but that's just a guess.)  But given that the functional side of the audience does seem to care passionately, and I certainly don't, I'm willing to recant my opinion so long as we come up with some intuitively consistent approach...



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

Fascinating discussion. It seriously reminds me of the raging debates i have hosted in the confines of my puny skull over similar naming options. So many trade-offs to explore. So little time.

Stepping back, i believe the conversation at hand suggests "names with structure" is a concept that has some weight and bearing on the issue. It really doesn't have to be left entirely to convention. There are good explorations of algebras for names that make sense, such as Milner's "naming" monoids or Carbone's paper on polyadic synchronization, or even Meredith and Radestock's paper on namespace logics ;-).

Less abstractly, take a look at the periodic table of the elements. The names for the elements are not the symbols. The names are the positions in the table. From these structured names one can predict types of interactions. Furthermore, the invention of the periodic table really marks the transition from alchemy to chemistry. When will programming language design make a similar transition?

Best wishes,

--greg

On Tue, May 12, 2009 at 8:03 AM, Walter Chang <weihsiu [at] gmail [dot] com> wrote:
+1 for incl/excl

On Tue, May 12, 2009 at 7:32 PM, Landei <Daniel [dot] Gronau [at] gmx [dot] de> wrote:

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

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




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



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

+1 206.650.3740

http://biosimilarity.blogspot.com
mighdoll
Joined: 2009-02-16,
User offline. Last seen 1 year 22 weeks ago.
Re: Re: Naming collection operations
And if we need commutative replacements for +/-, perhaps:
    :->, makes a set fat and happy
and
    :-<, makes a set empty and bereft
jokes are not commutative, so the symbol works.

Weak humor aside, naming is important.  I like with/without. 

What's 'with' reserved for and can we unreserve it?

Lee
Erkki Lindpere
Joined: 2008-12-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Naming collection operations

n case this question is still open, my suggestion is

having/lacking

Erkki

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

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