rewrote singleton objects tour #704
Conversation
travissarles
force-pushed
the
singleton-objects
branch
from
60df162 to
80e7d86
Compare
| Methods and values that aren't associated with individual instances of a [class](classes.html) belong in *singleton objects*, denoted by using the keyword `object` instead of `class`. | ||
| Singleton objects are like classes in that they contain methods and values, but there are a few key differences. | ||
| * There is only one instance of a singleton object so their methods and values aren't associated with individual instances of a [class](classes.html). | ||
| * Objects have no constructors so they cannot be instantiated |
There was a problem hiding this comment.
This language has to be wrong and misleading. The spec says it nicely: "a single object of a new class." I might have preferred "a single instance of a new class." Occasionally, you have to be aware of when object init happens, including common use cases with circular definitions.
There was a problem hiding this comment.
@som-snytt Looking back on it, I agree that it's a bit misleading. I like "a single instance of a new class" except that the word "class" could be confusing for people who assume that classes can be instantiated. I'll try to explain that. Thanks for the feedback.
travissarles
force-pushed
the
singleton-objects
branch
2 times, most recently
from
398ed84 to
641d066
Compare
|
|
||
| # Defining a singleton object | ||
| Like with classes, the simplest form of an object is the keyword `object` and an identifier: | ||
| ```tut |
There was a problem hiding this comment.
we should be marking code blocks tut whenever possible, so PR validation checks that the code compiles. see #677
|
|
||
| def blah = foo | ||
| } | ||
| The `class Event` imports `_isOnTheWeekend` from the `object Event`. To make a member inaccessible from outside, use `private[this]`. |
There was a problem hiding this comment.
To make it inaccessible from its companion class you mean. It is inaccessible everywhere else with just private
There was a problem hiding this comment.
Right, I'll change the wording.
|
|
||
| Note: If a class or object has a companion, both must be defined in the same file. To define them in the REPL, you must enter `:paste` and then paste in the class and companion object code. | ||
|
|
||
| ## Sharing global state |
There was a problem hiding this comment.
This is such a bad practice I'm not sure it's a good idea to give it as an example. If yes, I'd change the tone and make it "Beware of global state", and end with a thread-safe example.
travissarles
force-pushed
the
singleton-objects
branch
from
641d066 to
f6c1f91
Compare
|
|
||
| # Defining a singleton object | ||
| Like with classes, the simplest form of an object is the keyword `object` and an identifier: |
There was a problem hiding this comment.
I don’t really understand the connection with classes, so I wouldn’ start with “like with classes”.
|
|
||
| def blah = foo | ||
| object Event { | ||
| private def _isOnTheWeekend(date: LocalDateTime) = Array(DayOfWeek.SATURDAY, DayOfWeek.SUNDAY).contains(date.getDayOfWeek) |
There was a problem hiding this comment.
I’m not sure to see any advantage of putting this as a private def in the companion object. I think that maybe more compelling use cases for companion object’s methods are constants definition, default instances and alternative constructors.
travissarles
force-pushed
the
singleton-objects
branch
from
f6c1f91 to
4a598b2
Compare
|
@heathermiller ready to merge |
|
Both the old and new texts assume that Since the old text also had this problem, I think this PR could be merged anyway, but Travis, perhaps you're motivated to add some wording that addresses this? If not, perhaps we (or someone) can come back to it later. Otherwise LGTM for merge. |
travissarles
force-pushed
the
singleton-objects
branch
from
4a598b2 to
8af6f3a
Compare
|
Rebased at #978 |
No description provided.