On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:
I mean, usually we need to do a cost/benefit analysis, ...
The benefit is explained in my opening discussion.
That is, i can have more than just a single class in a module
file, as still be able to 'program to the interface' of the
class, rather than implicitely give all other code in that module
access to the private parts of my class.
Programming to the interface, is clear design philosophy of mine.
Which is why I actually like the C++ friend attribute - because
that is an explicit part of the defined interface.
An additional benefit is, that a class not marked as sealed (in a
module), is a warning sign that anything else in the module (but
outside of the class), may ignore the your class interface (i.e.
can access it's private parts). So it could be helpful attribute
for the way in which you approach analysing the code within the
module.
For me, personally, I see this as a benefit. I do not see any
downside (from a user perspective).
It does not change the benefit others get from having the status
quo - which would remain unaffected - and while the status quo
does indeed have benefits (as I've discovered in the other
thread), it also has retains the downside of other local code in
the module being able to bypass a declared interface.
If people want to propose putting each class in it's own module,
that does not address my requirements, and therefore is not
helpful to this discussion.
