1

Is it safe to assume that:

because scala.AnyRef defines toString() and hashCode() with a pair of parenthesis due to interoperability with Java (as suggested by Martin in: https://groups.google.com/forum/#!topic/scala-language/RlV9O1RDmis),

every single class in the Scala standard library that is a descendent of scala.AnyRef defines toString() and hashCode() with a pair of parenthesis ?

In other words, can I trust that the developers of the standard library were consistent in using toString() and hashCode() for the descendent classes of AnyRef?

Edit - changed the question to ask only for descendent classes of AnyRef

platypus
  • 1,165
  • 5
  • 27
  • 47
  • As a side note: I'm not sure what you mean by "implicitly extends", but it's not really the case that every class in the standard library is a subclass of `AnyRef`. – Travis Brown Sep 03 '12 at 20:24
  • By that I mean a descendent somewhere in the hierarchy (since AnyRef is the root class of all reference types). I guess a better way to phrase the original question is, do all descendents of AnyRef (not AnyVal) implement toString() and hashCode() with a pair of parens. But as you said, a grep will answer that =) – platypus Sep 03 '12 at 20:30
  • I'm just curious—what's motivating the question? – Travis Brown Sep 03 '12 at 20:41
  • It's really a matter of using toString vs toString(). But as you know, you can invoke both methods with just "toString". The best practice is to use toString when there is no side effect and to use toString() when there is. It would annoying if you had to look up which method (toString vs toString()) is used by the library class that you want to use. Therefore I thought if all descendents of AnyRef implemented it with "toString()", then I can stick with that convention. – platypus Sep 03 '12 at 20:50
  • Java doesn't care or even know whether you defined your method with `()` or not. The only problem you might encounter is if in Scala you start using `.toString()` with parens everywhere, it sometimes won't work. The whole no parens / parameterless / zero param methods confusion borders on insanity, but I think it could be fixed if `noParamMethod()` meant `noParamMethod` rather than `noParamMethod.apply()` (who ever uses zero-arg apply methods?). – Luigi Plinge Sep 03 '12 at 20:51
  • What's the best practice or convention you follow when calling a library function's "toString or toString()" method? Do you go on the website to look up which one it uses? Or do you just pick "toString" for simplicity? What I really want to do is to find a page on the API online of a descendent of AnyRef that explicitly does a "def toString: String". Basically a public class (descendent of AnyRef) that uses toString. So far I can't find any. It seems like all publicly available ones are "def toString(): String" with a pair of parenthesis. – platypus Sep 03 '12 at 21:09
  • `toString` shouldn't ever have side-effects, so don't use the parens. – Luigi Plinge Sep 03 '12 at 21:10

1 Answers1

4

Since all you need is one counterexample, here you go:

object Int extends AnyValCompanion {
  ...
  override def toString = "object scala.Int"
}

But grepping for "toString[^(]" on the standard library source turns up hundreds of others.

Note that the ability to override a method with an empty parameter list with a parameterless one was explicitly added to the Scala language specification in Scala 2.0.

Community
  • 1
  • 1
Travis Brown
  • 138,631
  • 12
  • 375
  • 680
  • So at the end, what I was really looking for was a page on the Scala API that shows a descendent of AnyRef providing a toString method with the "def toString: String" signature. Grep showed me a lot of results but all the ones I saw were either coming from inner classes or private classes. Thanks for your help anyways! – platypus Sep 03 '12 at 21:21
  • What do you mean? My example is the companion object for `Int`—it's definitely not either an inner or private class, and it definitely descends from `AnyRef`. The [API documentation page](http://www.scala-lang.org/api/current/scala/Int$.html) shows the signature with `()`, but that's just a quirk of ScalaDoc. – Travis Brown Sep 03 '12 at 21:55
  • Oh I see, it's a "quirk of ScalaDoc." Now I get it. In general, should I just pick "toString" for all calls for the sake of simplicity? Again thanks a lot! – platypus Sep 03 '12 at 22:07
  • Yes, for sure when you're calling `toString`. I also personally avoid the parentheses when I'm overriding `toString`, but that's more a matter of taste. – Travis Brown Sep 03 '12 at 22:10
  • And by "quirk of ScalaDoc" I just mean it reflects the signature of the original method, not the signature that the `Int` object's implementation actually uses. – Travis Brown Sep 03 '12 at 22:13
  • Okay cool. I confirmed that in the source code of Any.scala, the original method signature was indeed, "def toString(): String" . so the quirk reflected that signature! The inheritance line of Int object is: AnyValCompanion, SpecializableCompanion, AnyRef, Any. So since Any is at the top, it is the owner of the original method. – platypus Sep 04 '12 at 04:13