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

KingJoffrey KingJoffrey at KingJoffrey.com
Fri May 18 15:40:52 UTC 2018


On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:
>
> As clean and uncontroversial as this proposal might be, it 
> unfortunately doesn't resolve the biggest issue. If you try to 
> write Java code in D, you're still going to be using private, 
> and you're still going to be caught by surprise.

This is simply unavoidable - and, that 'surprise' you mention, is 
already there - it's not dependent on, or in any way related, to 
any proposal that might result from this discussion.

The D 'private is really public in a module' concept, is here to 
stay (sadly, but it's true).


> And this is another step in the direction of C++ (we need to 
> think of beginning programmers every so often) so there are 
> costs. It's possible that since I rarely use classes I'm not 
> seeing the large benefits.

C++ is a complex beast, as a result of both needing to accomodate 
change (evolve), and not wanting to break backwards compatability.

It's still *the* most powerful and flexible tool available for 
programmers.

Beginner programmers would do well to keep that in mind.

A class is just an abstract type, a tool for those that think it 
is useful in the solution for their problem domain.

In any case, this discussion is not about convincing you of the 
value of classes - you should already know that if you are 
programmer.

This discussion (at least my reason for being involved in it) is 
about breaking this idiotic (in my opinion) concept that D 
enforces on 'everyone' - i.e the one class per module, or 
everything is public, and you have no say in it.

I don't necessarily object to the freedom the D module provides 
(i.e to bypass your interfaces, even accidently). What I object 
to is the 'i.e the one class per module, or everything is public, 
and you have no say in it.'

A proposal that empowers the programmer to use the module for 
more than just a container for single class, coupled with static 
compile time verification - i.e you can't accidently access your 
private(this) T as it would be a compile time error, would be 
good for D (in my opinion), because those that have enjoyed 
having this capability in other mainstream langauges for 
literally decades!, won't be shut out from using D.

It will attract more programmers, not less - and trust me, D 
better get more programmers using it, cause 18 years on, and it 
hasn't got that far, really.

To get more programmers, you might want to be more open to 
accomodating their needs too.

Although I do wonder, sometimes, whether the aim if D is just to 
be this cosy little langauge that not many use, except for those 
that do.



More information about the Digitalmars-d mailing list