Intended Security Hole?

[Maxim Fomin]

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.