Hacker News new | ask | show | jobs
by felipehummel 5316 days ago
I also believe it is nonsense to overuse symbols for methods. I think even Martin Odersky agrees (I've read somewhere).

I guess this is something that will settle down eventually. And programmers will stop using so much random symbols instead of English.

For the specific case of Lists, I don't think is that much trouble. It is the most important class of the language. You better get used to it anyway.

1 comments

my point is that this style of writing is pervasive within the scala world, including the official api. and it's not just the list class. look at the base xml class, NodeSeq:

http://www.scala-lang.org/api/rc/scala/xml/NodeSeq.html

The xml stuff is more the exception than the rule. They've moved away from that approach. Whether to keep it at all has been discussed quite a bit. It would be more fair to look at the newer code in the collection framework to paint what is considered "best practice" by the creators of Scala.
These operators such as ++ (concatenation) etc are uniformly available in all collections. It has inherited these operators from base sequence classes/traits specifically TraversableLike.

http://www.scala-lang.org/api/rc/scala/collection/Traversabl...

If you write a fancy skiplist and add a TraversableLike trait you will get these operators and the associated methods for free!

Check the source code for NodeSeq. https://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_...

It does not implement any of these operators. It just inherits some features extends immutable.Seq[Node] with SeqLike[Node, NodeSeq] with Equality

provides an equality operator and a builder and gets all the other collection operators for free. These operators have the same semantics and implementation across all collection classes unless you specifically override them.

??? These are the same methods. It is common in languages with inheritance that classes implementing the same types have pretty much the same methods available ...