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.


[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

Reply via email to