This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Random thoughts about class signatures in ScalaDoc.regarding Any/AnyRef/AnyVal/Nothing

5 replies
soc
Joined: 2010-02-07,
User offline. Last seen 34 weeks 5 days ago.

Hi everyone,

I was just reading in ScalaDoc a bit and got annoyed of the "extends
AnyRef"
in many class signatures.

It's not that classes wouldn't have enough things to inherit from
(collection
classes are a good example) :-), but maybe it is possible to decrease the
amount of clutter in the class signatures?

I'll try to sketch the way my thoughts went, eventually leading to the
decision to write this mail:

[It would be nice to not show Any and AnyRef in ScalaDoc since
every reference type inherits from them anyway...]
|
v
[But what about value types?]
|
v
[Maybe it would work using a different kind name for them?]
|
v
[Could it work to keep using class/trait/object for reference types
and replacing "final class Boolean/Int/... extends Any with AnyVal"
with something like "value Boolean/Int..."?]
|
v
[But what about Nothing? It is supposed to be a subtype
of everything... and the code says "final trait Nothing"]
|
v
[Better to use "type Nothing" maybe? The ScalaDoc also only
talks about "type/subtype" and not about "class/subclass" anyway.]

In the end, would it make sense to show a slightly more high-level view
of Scala's type hierarchy to the user, where Any/AnyRef/AnyVal isn't
shown explicitly in the type signature in favor of a more implicit

"class/trait/object Foo" => Foo must be subtype of AnyRef
"value Bar" => Bar must be subtype of AnyVal

instead of

"class/trait/object Foo extends AnyRef"
"final class Bar extends Any with AnyVal"
?

What about "final trait Nothing"?

While I like how that "impossible" modifier combination conveys
the idea of an "uninhabited" type, wouldn't it be nicer to
just use "type" instead?

(Considering the fact that the compiler displays a not very helpful
error message when trying to compile "final trait Baz" about
"illegal combination of modifiers: abstract and final"...)

Just some random thoughts I was thinking about ... I did no deep
research into
type system theory, the ideas are just based on my personal taste.

What do you think?

Thanks and bye,

Simon

Seth Tisue
Joined: 2008-12-16,
User offline. Last seen 34 weeks 3 days ago.
Re: Random thoughts about class signatures in ScalaDoc.regardin

>>>>> "Simon" == Simon Ochsenreither writes:

Simon> In the end, would it make sense to show a slightly more
Simon> high-level view of Scala's type hierarchy to the user, where
Simon> Any/AnyRef/AnyVal isn't shown explicitly in the type signature
Simon> in favor of a more implicit

Simon> "class/trait/object Foo" => Foo must be subtype of AnyRef
Simon> "value Bar" => Bar must be subtype of AnyVal

I like the idea of dropping "extends AnyRef", but I think "value Bar"
departs too far from actual Scala syntax. I think "extends AnyVal"
would be fine though (and is an improvement on "extends Any with
AnyVal").

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Random thoughts about class signatures in ScalaDoc.regardin

On 4/20/11 11:19 AM, Seth Tisue wrote:
> I like the idea of dropping "extends AnyRef", but I think "value Bar"
> departs too far from actual Scala syntax. I think "extends AnyVal"
> would be fine though (and is an improvement on "extends Any with
> AnyVal").

https://lampsvn.epfl.ch/trac/scala/ticket/4445
"scaladoc says too much or too little"

Other examples of eliminable noise beyond "Any with AnyVal" include:

// every annotation
class cloneable extends Annotation with StaticAnnotation
// every case class
case class Some [+A] (x: A) extends Option[A] with Product with
Serializable

soc
Joined: 2010-02-07,
User offline. Last seen 34 weeks 5 days ago.
Re: Random thoughts about class signatures in ScalaDoc.regardin

Hi,
>> I like the idea of dropping "extends AnyRef", but I think "value Bar"
>> departs too far from actual Scala syntax. I think "extends AnyVal"
>> would be fine though (and is an improvement on "extends Any with
>> AnyVal").
Mhh, considering the fact that the user can't really define any new
AnyVal classes, how would he know that the "right" syntax is "final
class" instead of e. g. "value/struct/data/bippy/..."?

Further considering that a "final class" extending "AnyVal" behaves very
differently from every other "class" (No nullability, no Constructor,
literals, etc. ...).

Yes, I think it would be a departure here ... but if that would enable
ScalaDoc to drop all this Any/AnyRef/AnyVal noise ... the price would
seem right. It is just that AnyRef can't really die without AnyVal
disappearing too imho.
> https://lampsvn.epfl.ch/trac/scala/ticket/4445
> "scaladoc says too much or too little"
>
> Other examples of eliminable noise beyond "Any with AnyVal" include:
>
> // every annotation
> class cloneable extends Annotation with StaticAnnotation
> // every case class
> case class Some [+A] (x: A) extends Option[A] with Product with
> Serializable
cool, thanks for that ticket.

I just wonder ... is there a reason why AnyVal is a "sealed trait"
(which leads to "extends Any with AnyVal" instead of "extends AnyVal")
instead of a "sealed abstract class"?

Afaik AnyVal will never appear in any bytecode, so it can be the
size/overhead of it, right? ("sealed abstract class" has ~200 bytes more
than "sealed trait")

Thanks and bye,

Simon

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Random thoughts about class signatures in ScalaDoc.regardin

On 4/20/11 11:47 AM, Simon Ochsenreither wrote:
> I just wonder ... is there a reason why AnyVal is a "sealed trait"
> (which leads to "extends Any with AnyVal" instead of "extends AnyVal")
> instead of a "sealed abstract class"?

Because I didn't manage to bootstrap the compiler that way. It is
pretty difficult to build the compiler while presenting it with a source
file for one of its core classes which is full of outrageous lies about
what is really going on. It took me several days full-time to get it
working where it is.

soc
Joined: 2010-02-07,
User offline. Last seen 34 weeks 5 days ago.
Re: Random thoughts about class signatures in ScalaDoc.regardin

Hi,
> Because I didn't manage to bootstrap the compiler that way. It is
> pretty difficult to build the compiler while presenting it with a source
> file for one of its core classes which is full of outrageous lies about
> what is really going on. It took me several days full-time to get it
> working where it is.
Ok, cool. Thanks for the explanation.

My question wasn't meant as any form of criticism, I was honestly
interested if there were any deep "theoretical backgrounds" why the one
would have been more correct than the other or something like that or if
it was for practical reasons.

Then I guess it might be easier to adapt ScalaDoc to show something
nicer instead of changing AnyVal.scala directly.

Thanks and bye!

Simon

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland