How can it be meaningful to have something private and unimplemented? It's a contradiction, since it's not inherited and can never be implemented and hence would prevent instantiation of any subtype of the trait bearing such a member.
–
Randall SchulzApr 5 '13 at 15:08

1

I'm not sure I follow you. If you need subclasses to define seed (overriding its definition) it doesn't makes sense to make it private. That said, the subclass that defines the implementation of the seed member will always be able to show it with a public accessor. I can't understand the need behind this design choice.
–
pagoda_5bApr 5 '13 at 15:09

I think it boils down to being able to let the direct sub-trait define the value of seed while making further sub-traits (and external code) be unable to access the value. Kind of like a protected value (treat like a protected value for the sub-traits, and treat as private for everything lese). As for the meaningfulness, I think the idea is just to fully emulate what can be done through parameters (in classes) as shown in his example.
–
Régis Jean-GillesApr 5 '13 at 15:43

2 Answers
2

A simple way to keep a val private while allowing the sub-traits to initalize it would be to define it as private but initialize it with the value returned by another protected method.
Then the sub-traits can define this protected method so as to change the initial value, but cannot access the value itself.
So you would change this:

trait A {
protected val foo: Bar
}

into:

trait A {
private val foo: Bar = initFoo
protected def initFoo: Bar
}

Now, only trait A can access the val foo. Sub-traits can set the initial value of foo by definint initFoo, but cannot access foo itself:

trait B extends A {
protected def initFoo: Bar = ???
}

Obviously, initFoo itself is still accessible by sub-traits.
This is often not a problem if initFoo creates a new instance everytime (in other words, it is a factory),
as we might only be interested in making the instance private to A without being concerned with having sub-traits being able to create new instances of Bar
(irrespective of whether the new instances are equals to foo as per their equals method).

But if it is a concern (and it certainly is in your case as seed is fo type Int and thus what you want to hide is a value and not just a reference),
we can use an additional trick to allow sub-traits to define initFoo but prevent them (and their sub-traits) from being able to call it.
This trick is, let's face it, pretty awful for such a simple need, but it illustrates a nice pattern for advanced access control.
Credits goes to the standard library authors for the idea (see http://www.scala-lang.org/api/current/index.html#scala.concurrent.CanAwait).

Now, if B tries to call initFoo, the compiler will complain that it could not find an implicit of type InitA (the unique such instance is A.initA and is only accesible to in A) .

As I said, it's a bit awful and the package private solution given by axel22 is certainly a much easier alternative (although it won't prevent anyone from defining their sub-traits inside the same package as yours, thus defeating the access restriction).

The best you could do is to declare these package private - private[package_name].
This would allow you to extend and define the trait within the same package in which you are doing your implementation, but disallow clients to use it from other packages.