On Wednesday, 22 June 2022 at 11:36:52 UTC, forkit wrote:
> Of course, this butchering does have an effect on OOP in D. But that's not the main point here.
In fact, you are always using abstract data types, and benefitting from them, regardless of what 'paradigm' you're using.
Yes, yes, yes, but many D programmers don't have formal training so they are going by what they read on blogs or their own experience.
It should be obvious to anyone that if D's strength is to go from prototyping to shippable products then solid support for evolution is needed. Fine grained encapsulation is absolutely an advantage. That's 100% undeniable. Especially in system level programming.
However, if I were to rank what should be focused on, then changing/adding to encapsulation would be at spot 20 or so…
Currently the big issue for D is not loosing focus and complete what has been started on:
- competitive memory management
- @safe and @trusted
- completing existing features
- fixing error handling
- fixing contracts
When all that is done… by all means, look at encapsulation, syntax, etc.
But I would predict that the end result, after everyone has added/changed their pet peeve, would be something that would not be D2, it would be D3.
So the best option is to either make do with naming-conventions to get ad-hoc class-privacy or implement it as a fork.
If you want to do this in a fork then I'll try to help you with locating the spots that need modification. If you complete this on a fork, I'll help you write the DIP for it.