-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider changing layout of objects and traits in the types package #416
Comments
Another advantage of the proposed layout is that |
Here are more advantages: // current layout
scala> val x = all.NonEmptyString(".")
x: all.NonEmptyString = .
scala> val y = string.NonEmptyString(".")
y: string.NonEmptyString = .
scala> implicitly[all.NonEmptyString =:= string.NonEmptyString]
res10: all.NonEmptyString =:= string.NonEmptyString = <function1>
scala> implicitly[all.NonEmptyString.type =:= string.NonEmptyString.type]
<console>:36: error: Cannot prove that all.NonEmptyString.type =:= string.NonEmptyString.type.
implicitly[all.NonEmptyString.type =:= string.NonEmptyString.type]
^ // proposed layout
scala> val x = all.NonEmptyString(".")
x: string.NonEmptyString = .
scala> val y = string.NonEmptyString(".")
y: string.NonEmptyString = .
scala> implicitly[all.NonEmptyString =:= string.NonEmptyString]
res1: all.NonEmptyString =:= string.NonEmptyString = <function1>
scala> implicitly[all.NonEmptyString.type =:= string.NonEmptyString.type]
res2: all.NonEmptyString.type =:= string.NonEmptyString.type = <function1> There are two differences:
|
I think it's worth it. It's cleaner and like you said, creates less instances. |
The proposed layout also matches how the standard library makes some types available in the package object scala {
...
type Vector[+A] = scala.collection.immutable.Vector[A]
val Vector = scala.collection.immutable.Vector
...
} I'm convinced. This will happen in 0.9.0. |
From
to
The latter has the benefit that if one types
NonEmptyString
in a file that hasn't already imported that symbol, IntelliJ will be able to autocomplete the name and automatically importstring.NonEmptyString
if the name is completed. If the actual definition ofNonEmptyString
is in a trait, IntelliJ is able to autocomplete the name but won't import it sinceStringTypes.NonEmptyString
cannot be imported.I'm hesitant to make this change purely because of ergonomics of one IDE, so I'm still looking for other justifications for this change.
This layout is not binary compatible with the current layout and needs to be done in 0.9 or later. It seems to be source compatible though.
The text was updated successfully, but these errors were encountered: