Construct immutable member in derived class

[Jonathan M Davis]

On Thursday, April 05, 2018 13:36:07 Alex via Digitalmars-d-learn wrote:
> On Wednesday, 4 April 2018 at 21:49:08 UTC, Timoses wrote:
> > "[...] the construction of the base class can be independent
> > from the derived one."
> >
> > Hm, the points 7 and 8 don't clearly state what you wrote.
>
> Yes :)
>
> > But it somehow does make sense.. Still I wonder why that is so.
> >
> > Let's say you have an abstract class with immutable members.
> > Why shouldn't derived class constructors be allowed to
> > initialize these immutable members?
>
> My reason is a semantic one, so it's rather how I'm explaining
> this to me, then a formal one.
>
> Let's assume, we abstract away a member from different derived
> classes to an abstract class, which cannot be handled by this
> abstract class.
> Ok, this can happen, so it would be ok, if the base class does
> not handle the var.
>
> But then, we add a qualifier. How can this be? As the abstract
> class cannot handle the abstraction, it also can not add any
> qualifiers.
> As the qualifier is there, then, the base class at least has
> knowledge about the immutability. And due this fact, its own
> constructor has to handle this variable in some way.
>
> However, this a minor problem, isn't it? If you argue, that you
> can also abstract the immutability qualifier, then, I would say,
> that a derived class always has a better knowledge how to handle
> its members, and therefore how to call the base class
> constructor, as it knows which class it is derived from.
>
> So, for short:
> Either: the immutability belongs to the base class and therefore
> it has to manage the var
> Or: it doesn't and the derived classes have the knowledge how to
> serve their base class.

The reality of the matter is that a member variable is a member of the class
that it's in and _must_ be handled by that class. If it's not directly
initialized in its declaration or initialized in that class' constructor,
then it gets a default value. Derived classes have _zero_ control over that.
They can mutate a public or protected mutable member of a base class, but
that member variable still has to be initialized by the base class, not the
derived class.

And you can't abstract whether a member variable is marked with immutable or
not. That's part of the variable. Declaring an immutable instance of an
object would then treat the member variable in immutable for that instance,
so it's possible to have an immutable member variable when the member
variable is not itself marked with immutable, but class inheritance has
nothing to do with controlling which type qualifiers were used on the member
variable of a base class. Derived classes override member functions. They
don't override member variables or anything about them. They override the
behavior of the base class, not the structure. For them to do otherwise
would become quite problematic if you ever use a derived class through a
base class reference. They can add onto the structure of a base class, but
the derived class must be usuable via a base class reference, and trying to
do something like have the derived class alter the qualifiers on base class
member variable simply would not work with that. That sort of thing could
only ever work if the base class were just a way to add functionality to a
derived class rather than having anything to do with references, and that's
simply not how classes work in D. If that's the sort of thing that you want,
it would make more sense to add the functionality via composition rather
than inheritance.

- Jonathan M Davis