Sealed classes - would you want them in D? (v2)

KingJoffrey KingJoffrey at KingJoffrey.com
Thu May 17 05:06:54 UTC 2018


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.



More information about the Digitalmars-d mailing list