On Tuesday, 13 March 2018 at 06:58:08 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
The same applies here. Encapsulation simply isn't broken by
this feature.
What you're saying, is in D, class encapsulation is really
'module' encapsulation.
I get it. Fine. It's an intersting design decision.
But, in doing that, D has shifted the boundary of class
encapsulation, to a boundary that is outside the class.
To me, that sounds like D has broken class encapsulation. I
don't know how else one could describe it.
I continue to think, that class encapsulation is sacred, a well
defined, well understood, concept that has been around for a
very long time.
private could have still meant private, and surely someone
could have come up with a different access modifier to mean
'private at module level'.
Was that too hard the language designers?
Was it not hard, but just to complex to implement?
I don't get it.
I agree that class encapsulation is broken, well, not broken but
just not a thing really. Don't think it's a bad thing though.
Case in point, swift had private as file level access, swift 3
they introduced fileprivate [0] to do that instead and had
private be scope level (which includes class level and is what
you're referring to private being).
Swift 4 they reverted it .... kinda [1]
It was too inconvenient to not allow access to private members
within a file in a language that allows extensions (think ufcs).
So they compromised a bit here and went for decleration level
which makes sense within their extension semantics. This would
not work for D thought because ufcs is not really a type
extension (i.e. not part of a type's typeinfo)
So now the difference is that private can be used in a file but
only in a declaration and fileprivate can be used anywhere in a
file. So they allow class encapsulation but at a file level. It's
an interesting approach and quite neat.
Rust is also the same as D I believe. Module is the unit of
encapsulation.
I wouldn't want private to change it's meaning quite frankly in
the module system. I would not mind more control within a module
though because, well, encapsulation. A Rust-ish approach were you
can define a path [2] might allow for a lot more freedom but I'm
not sure how well that would work with D.
Cheers
[0]
https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md
[1]
https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
[2]
https://doc.rust-lang.org/beta/reference/visibility-and-privacy.html
