Silly question

[Jason House]

janderson wrote:

> Ary Borenszweig wrote:
>  > janderson wrote:
>  >> Jarrett Billingsley wrote:
>  >>> "janderson" <askme at me.com> wrote in message
> news:fuorvl$2j02$1 at digitalmars.com...
>  >>>
>  >>>> They are however in my book this is plain wrong.  The whole
> purpose of being able to hide abstraction layers is broken.  I should be
> able to protect inherited functions from objects that work on that
> level.  Its a fundamental principle in C++.
>  >>>
>  >>> What?
>  >>>
>  >>> Am I the only one who can't understand what this post means?
>  >>>
>  >>
>  >>
>  >> I have a interface:
>  >> (I'm using C++ because this won't work in D)
>  >>
>  >> class OnRenderI
>  >> {
>  >>    public:
>  >>     virtual void OnRender() = 0;
>  >> };
>  >>
>  >>
>  >> I have a derived class:
>  >>
>  >> class A : OnRenderI
>  >> {
>  >>    public:
>  >>     A() {  GetRender().Add(Me); }
>  >>    private:  //Or protected
>  >>     virtual void OnRender(); //This is good private
>  >> }
>  >
>  > Are you decreasing the visibility of method OnRender? I don't get it...
>  >
>  > void foo(A a) {
>  >   a.OnRender(); // nope, it's private
>  >
>  >   OnRenderI r = (OnRenderI) a;
>  >   r.OnRender(); // Now it's public??
>  > }
>  >
>  > I'm sure misunderstanding something...
> 
> Yep
> 
> You can also go in C++.
> 
> OnRenderI r = a; //No cast required (automatic upcast)
> 
> so:
> 
> a.OnRender(); //Nooo
> 
> r.OnRender(); //Yes but calls a's OnRender();
> 
> 
> or
> 
> class Render
> {
> void Add(IOnRender a)=0;
> }
> 
> ....
> 
> A a;
> 
> render.Add(a); //Yes, a is automatically upcast.
> 
> -Joel

IMHO, this type of functionality becomes tough for anyone
reading/manipulationg the code to keep things straight.  While it certainly
is valid C++, I'm happy to see it's not in D.