25 ms·
Yes, it would work. "==" is a method like any other, and you're overriding it. You should download the Scala IDE and play with a feature called the "Worksheet"
by alexdias 14y ago
Yes, it would work. "==" is a method like any other, and you're overriding it.
You should download the Scala IDE and play with a feature called the "Worksheet".
See here: https://github.com/scala-ide/scala-worksheet/wiki/Getting-Started https://github.com/scala-ide/scala-worksheet/wiki/Getting-St...
- rudasn 14y agoCool thanks. 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 :)
- Bjartr 14y agoIt's certainly possible to get out of hand with operator overloading, especially if you try. Take this implementation of "analog literals" in C++ http://www.eelis.net/C++/analogliterals.xhtml http://www.eelis.net/C++/analogliterals.xhtml
- weego 14y agoThere 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 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).
- cheald 14y agoFor 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.