For that matter, it's an incredibly anachronistic and inaccurate usage of systems programming. People generally reserve systems programming to problems that in order to be solved require something closer to gluing toothpicks than spraying memory.
On topic then, this is the first time I see Scala syntax and was somewhat pleasantly surprised (the only languages I really know are JavaScript and Python).
case class Stock(ticker: String, price: Double) {
def <(other: Stock) = price < other.price
}
val goog = Stock("GOOG", 675.15)
val aapl = Stock("AAPL", 604.00)
aapl < goog == true
goog < aapl == false
Correct me if I'm wrong but it seems to me that the class Stock gets a method called "<". So appl.< google (or the other way around) would also work. The previous slide also shows this, but the Stock example is makes it even clearer that "Scala is a pure object oriented language: every value is an object." appl and goog are objects, of type Stock, and < is an object, a method of Stock.
I wonder if this kind of method would work
def ==(other: Stock) = price != other.price
and what would happen if it was like this
def ==(other: Stock) = self != other
(where self would be a reference to the Stock instance, ala python, or this in javascript)
Isn't this ability a bit dangerous or worrisome? It means that for every Scala package you use you need to review the code. It does make a good prank though :)
There is a library called Dispatch that has/had this problem entirely, the author decided to use symbols instead of natural language method names and left it fairly undocumented, so you had to spend time reading the source to have any idea what was going on. To the point where a kindly soul decided to write a periodic table (http://www.flotsam.nl/dispatch-periodic-table.html) to help people with its use.
I wouldn't say it was particularly dangerous, but it is a massive pain to deal with (it also means you can google for any help with a particular method).
For what it's worth, this is how Ruby operates, as well - "a + b" is really "a.+(b)". In practice, it doesn't end up being very dangerous. Maybe it's just a community thing (the potential for abuse is certainly there), but it means that you get some really nice, natural-feeling code when you do need to use those overrides.
