On Thursday, 25 October 2012 at 10:29:12 UTC, Manfred Nowak wrote:
Maxim Fomin wrote:
b= d2;
What is wrong here?
The slight change in behavior might be unexpected and not
intended for
the owner of variable `Base b;'.
Then disable behavior by marking class or function as a final.
What is the price ( i.e. coding time, execution time, execution
space)
the owner of that variable has to pay in the case that she/he
want
expectable behaviour only and owns the variable `b' but not the
source
of its type `Base' and has to provide some access to variable
`b'?
In essence: kills the ability of "aspect programming" the
intent of
"information hiding"?
But is not hijacking, it is inheriting.
Variables can not be inhereted, only types. It seems to be
euphemistic,
to name "information steeling from" or "information changing
of" a
variable by the conceptual term "inheritance".
-manfred
What is "information steeling from" and "information changing of"
here? You deliberately created derived classes and passed
instances of them where base class instances were expected. Why
now you are complaining about this?
You can use UFCS to do what you want (what I guess you want)
because UFCS and virtual functions don't work now:
http://dpaste.dzfl.pl/d6eafd71. But be hurry because UFCS
admirers who found logic in making every feature work in
accordance with UFCS can found this loophole. Also similar effect
can be achieved by making functions private.
BTW, you started thread with caution regarding replacing
implementation of functions without bodies during runtime -
please, provide an example how you can do this.
