Naming collection operations

[Johannes Rudolph-2]

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

--
Johannes

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

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

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.

[Josh Suereth]

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

[David MacIver]

2009/5/12 Larry Yogman <lyogman@...>:

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

[Stepan Koltsov-5]

On Tue, May 12, 2009 at 16:26, Larry Yogman <lyogman@...> 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-5]

On Tue, May 12, 2009 at 16:34, David MacIver <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]

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

[bearfeeder]

On Tue, May 12, 2009 at 2:54 AM, 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.

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

[csar]

plus/minus "reads" as +/-

On Tue, May 12, 2009 at 12:47 PM, Viktor Klang <viktor.klang@...> 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.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

[Viktor Klang]

On Tue, May 12, 2009 at 3:31 PM, Carsten Saager <csaager@...> wrote:

plus/minus "reads" as +/-

On Tue, May 12, 2009 at 12:47 PM, Viktor Klang <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 <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

--
Viktor Klang
Senior Systems Analyst

[Seth Tisue]

Agreed that "plus" and "minus" are just about the worst possible choices
(I should have spoken up sooner).

I woud argue against "add" and "remove" because they are verbs which have
a strong imperative flavor; they sound like they mutate.  What is "add"
if not "plus" plus mutation?

I think including/excluding are fine.

--
Seth Tisue / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[Ricky Clarkson]

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 <viktor.klang@...>:

>
>
> On Tue, May 12, 2009 at 3:31 PM, Carsten Saager <csaager@...> wrote:
>>
>> plus/minus "reads" as +/-
>>
>> On Tue, May 12, 2009 at 12:47 PM, Viktor Klang <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
>>> <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
>>
>
>
>
> --
> Viktor Klang
> Senior Systems Analyst
>

[Landei]

Viktor Klang wrote:

joinWith/partWith?

glue/unglue?

and/not ?

--
Viktor Klang
Senior Systems Analyst

shoveInto/yankOut ?

[Viktor Klang]

On Tue, May 12, 2009 at 3:52 PM, Landei <Daniel.Gronau@...> 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

[Geoff Reedy]

Here's another -100 for "plus" and "minus" and a +1 for "including" and
"excluding".

To me it would be horribly inconsistent to have both +/- and plus/minus
where "plus" doesn't do the same as "+" and "minus" doesn't do the same
as "-", even if it is temporary. It becomes even worse if +/- return
this as they do for current mutable collections since the difference
between their use becomes even smaller, and as a result much more
important.

-- Geoff

[Jorge Ortiz-3]

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

On Tue, May 12, 2009 at 2:54 AM, 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.

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]

On Tue, May 12, 2009 at 5:54 AM, David MacIver <david.maciver@...> 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 Dickens-2]

I thought + and plus WERE supposed to do the same thing. Ditto - and minus.

Please could everyone make sure they've read (and fully understand) Martin's initial post.

2009/5/12 Geoff Reedy <geoff@...>

Here's another -100 for "plus" and "minus" and a +1 for "including" and
"excluding".

To me it would be horribly inconsistent to have both +/- and plus/minus
where "plus" doesn't do the same as "+" and "minus" doesn't do the same
as "-", even if it is temporary. It becomes even worse if +/- return
this as they do for current mutable collections since the difference
between their use becomes even smaller, and as a result much more
important.

-- Geoff

--
Rob, Lafros.com

[David MacIver]

2009/5/12 Rob Dickens <arctic.bob@...>:
> I thought + and plus WERE supposed to do the same thing. Ditto - and minus.
> Please could everyone make sure they've read (and fully understand) Martin's
> initial post.

You mean the bit where he said:

> To help users migrate, + and - will stay side-effecting on mutable collections for the time being but will be deprecated there.

and

> We need a good letter-based name for the purely functional version of these methods.

for example?

[bearfeeder]

On Tue, May 12, 2009 at 7:26 AM, Jorge Ortiz <jorge.ortiz@...> 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.of.the.bears@...> wrote:

On Tue, May 12, 2009 at 2:54 AM, 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.

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