So there seems to be quite an emphasis at the moment on simplifying Scala, getting rid of unnecessary complication. What about reducing the number of access categories to 2 and reducing the number of access modifiers to 1? So there would just be public and private[this]. But private[this] would be renamed private. So “private” would be the only access modifier, but it would have the same meaning as private[this] under the present schema.
I very occasionally use protected, but at least for my code, I don’t really feel the feature carries its weight and I would be willing to sacrifice it in the cause of simplicity. A less radical proposal would be to keep 3 categories:
Unmodified default => public
protected => protected[this]
private => private[this]
I’d appreciate private meaning private[this], I have never seen a case where you want private in Scala, you just often write private because private[this] is ugly and verbose.
Actually thinking about it, I think protected[this] is the most useful access condition after public. I doubt there are many situations where private[this] really gives you significant advantage over protected[this]. So I would change my proposal to a single access modifier:
Unmodified default => public
private => protected[this]
You need private because you don’t want an API that becomes binary (MiMa) or source incompatible at the slightest internal change. You need protected for trait mixins composition of implementations. So I think the list is
public
protected (I don’t mind if its protected[this] by default, but you don’t gain much, so better leave it open)
private[this] - which should thus be called private
You could also say you don’t gain much from private to private[this] change, but AFAIK you need the latter for a val to become an actual field in the byte code (correct me if I’m wrong).
Um – I use package-private almost exclusively. It’s basically the only time I don’t just leave things public; it’s how I distinguish between public and internal APIs in a library or subsystem. So I really don’t agree here…
I second @jducoeur on this one.
It’s particularly useful when you need to expose some fiddly isternal logic to the tests, but don’t want it part of the exposed API
But you mean by package private, something like private[foo], no? Just to clarify, I am not suggesting to remove that (and I guess in that and other respects I don’t share the proposal of the OP), and I use that too, indeed. Just saying that private with access across different instances of the same type is quite an esoterical use case IMO.
Edit: Of course, if the compiler could automatically treat private as private[this] when applicable (it could determine it from the exact same compile unit, I guess?), then one wouldn’t need to change anything from the programmer’s point of view.