www.digitalmars.com         C & C++   DMDScript  

D - object framework inheritance

reply Patrick Down <pat codemoon.com> writes:
One idea I've always liked is support for object framework 
inheritance.

For example consider a GUI class hierarchy.  You might have
an application class, a window class, a document class.  From
these you might derive several different window classes like
controls, frame windows, and views.  From the control class you 
might derive a 100 different control class types.

This is nothing new we've all seen many different GUI class frameworks
The GUI framework supports all the default behavior for a GUI
application you just need to extend it for your application,
The problem that I've found is that eventually you want to implement
a new feature in the GUI that is universal across the framework.

For example the GUI framework doesn't support layout managers.  You
want to add layout mangers, but in order to do that you really want
to add features to the window class to cooperate with the layout manager.
You need to do it to the window class so that all the views and controls
will cooperate with the layout manager too.

Unfortunately the only really way to do this is to modify the source code
for the window class.

One way to get around this is to define and extend frameworks of classes.
An example syntax for this might be:


framework GUI
{
  class Application
  {
  }
  
  class Window
  {
  }
  
  class View : Window
  {
  }
  
  class Control : Window
  {
  }
  
  // Lots of other classes
}


framework MyGUI : GUI
{
  // This class inherits from the GUI::Window
  // and extends it
  class Window
  {
  }
  
  // Even though I don't derive a new View class
  // there is a new View in this framework that
  // inherits all the features of the new window
  // class as well as the view class features from
  // GUI::View
}


I got this idea a while back from an article by Tim Sweeney ( Unreal 
engine developer ) about computer languages and his opinions on what 
would be important future language features.   The article is at 
http://www.gamespy.com/legacy/articles/devweek_b.shtm for anyone that 
interested.

The framework specific stuff is here:
http://www.gamespy.com/legacy/articles/devweek_e.shtm
Mar 01 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns91C499D892980patcodemooncom 63.105.9.61...


   // Even though I don't derive a new View class
   // there is a new View in this framework that
   // inherits all the features of the new window
   // class as well as the view class features from
   // GUI::View


This sounds a lot like multiple inheritance to me,
only done implicitly... or am I wrong? Is MyGUI.View
castable to both GUI.View and MyGUI.Window?
Mar 01 2002
parent reply "Patrick Down" <pdown austin.rr.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a5ot0k$pth$1 digitaldaemon.com...

 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns91C499D892980patcodemooncom 63.105.9.61...


   // Even though I don't derive a new View class
   // there is a new View in this framework that
   // inherits all the features of the new window
   // class as well as the view class features from
   // GUI::View


 This sounds a lot like multiple inheritance to me,
 only done implicitly... or am I wrong? Is MyGUI.View
 castable to both GUI.View and MyGUI.Window?


Yes and No. :)

It depends on if you are looking a a syntactic
feature of the language or how it is implemented
under the hood.

No, it is not like multiple inheritance because
multiple inheritance can't elegantly do what's
done in the example.  A new feature is added
to perhaps a 100 classes in a framework
with only a few lines of code.

Yes, under the hood this could have the same
technical problems the multiple inheritance has.
If as you pointed out MyGUI.View can be cast to
GUI.View as well as MyGUI.Window then you have
the problem that C++ has under the hood with
multiple inheritance.

However you could say that MyGUI.View can't
be cast to GUI.View, they are in different
hierarchies. Now you could look at MyGUI.View
as an implicit cut and paste of GUI.View. I think
this is perhaps the correct way to view this
because of the example below.


Here's another example of how this is useful.
Sometimes you make classes that are designed
to be used together and extended together.
Model and View classes are an example of this.
Let's take a simple example with classes A and B.

class A
{
}

class B
{
  A theA;

  public:

  void SetObj(A a) { theA = a; }
  A GetObj() { return theA; }

  // Other stuff
}

Now the way you designed A and B they both need
to be extended by the person that uses them.

class C : public A
{
  // C specific stuff
}

class D : public B
{
  // D specific stuff
}

But there are a couple of problems.  For example
this can happen.

D theD = new D;

theD.SetObj(new A);
// Not an error but a problem because
// the programmer should have used a C class
// instead

Also when extending D you need to cast all the
time.

class C : public A
{
  void SomeFn()
  {
  }
}

class D : public B
{

  void SomeOtherFn()
  {
    ((C)GetObj()).SomeFn();
    // Must always cast for C specific
    // function
  }
}


With frameworks you could handle this problem
differently.

framework F
{
  class A
  {
  }

  class B
  {
    A theA;

    public:

    void SetObj(A a) { theA = a; }
    A GetObj() { return theA; }

    // Other stuff
  }
}

framework MyF : F
{
  class A
  {
    void SomeFn()
    {
    }
  }

  class B
  {

    void SomeOtherFn()
    {
      GetObj().SomeFn();
      // No casting problem. It will always
      // expect this to be MyF.A
    }
  }
}


MyF.B theB = new MyF.B;

theB.SetObj(new F.A);
// error My.B.SetObj takes a MyF.A
Mar 01 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Patrick Down" <pdown austin.rr.com> wrote in message
news:a5p7hs$uqu$1 digitaldaemon.com...


 Yes, under the hood this could have the same
 technical problems the multiple inheritance has.
 If as you pointed out MyGUI.View can be cast to
 GUI.View as well as MyGUI.Window then you have
 the problem that C++ has under the hood with
 multiple inheritance.

 However you could say that MyGUI.View can't
 be cast to GUI.View, they are in different
 hierarchies. Now you could look at MyGUI.View
 as an implicit cut and paste of GUI.View. I think
 this is perhaps the correct way to view this
 because of the example below.


   This is kind of cool. In a sense, you're talking about making an
extensible template (or macro) for a whole class hierarchy. The hierarchy is
not instantiated until it's used. And until then, all the classes can be
extended.

   Of course, you're opening a can of worms here, with sprinkled bombs in
the form of potential ambiguities and such.

   But I like the idea.

Salutaciones,
                         JCAB


 Here's another example of how this is useful.
 Sometimes you make classes that are designed
 to be used together and extended together.
 Model and View classes are an example of this.
 Let's take a simple example with classes A and B.

 class A
 {
 }

 class B
 {
   A theA;

   public:

   void SetObj(A a) { theA = a; }
   A GetObj() { return theA; }

   // Other stuff
 }

 Now the way you designed A and B they both need
 to be extended by the person that uses them.

 class C : public A
 {
   // C specific stuff
 }

 class D : public B
 {
   // D specific stuff
 }

 But there are a couple of problems.  For example
 this can happen.

 D theD = new D;

 theD.SetObj(new A);
 // Not an error but a problem because
 // the programmer should have used a C class
 // instead

 Also when extending D you need to cast all the
 time.

 class C : public A
 {
   void SomeFn()
   {
   }
 }

 class D : public B
 {

   void SomeOtherFn()
   {
     ((C)GetObj()).SomeFn();
     // Must always cast for C specific
     // function
   }
 }


 With frameworks you could handle this problem
 differently.

 framework F
 {
   class A
   {
   }

   class B
   {
     A theA;

     public:

     void SetObj(A a) { theA = a; }
     A GetObj() { return theA; }

     // Other stuff
   }
 }

 framework MyF : F
 {
   class A
   {
     void SomeFn()
     {
     }
   }

   class B
   {

     void SomeOtherFn()
     {
       GetObj().SomeFn();
       // No casting problem. It will always
       // expect this to be MyF.A
     }
   }
 }


 MyF.B theB = new MyF.B;

 theB.SetObj(new F.A);
 // error My.B.SetObj takes a MyF.A
Mar 01 2002
parent Patrick Down <pat codemoon.com> writes:
"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in
news:a5p8sn$vf3$1 digitaldaemon.com: 


 "Patrick Down" <pdown austin.rr.com> wrote in message
 news:a5p7hs$uqu$1 digitaldaemon.com...
 

 Yes, under the hood this could have the same
 technical problems the multiple inheritance has.
 If as you pointed out MyGUI.View can be cast to
 GUI.View as well as MyGUI.Window then you have
 the problem that C++ has under the hood with
 multiple inheritance.

 However you could say that MyGUI.View can't
 be cast to GUI.View, they are in different
 hierarchies. Now you could look at MyGUI.View
 as an implicit cut and paste of GUI.View. I think
 this is perhaps the correct way to view this
 because of the example below.


 
    This is kind of cool. In a sense, you're talking about making an
 extensible template (or macro) for a whole class hierarchy. The
 hierarchy is not instantiated until it's used. And until then, all the
 classes can be extended.
 
    Of course, you're opening a can of worms here, with sprinkled bombs
    in 
 the form of potential ambiguities and such.
 
    But I like the idea.
 
 Salutaciones,
                          JCAB
 


Yes, I think it's a very powerful concept but I fully 
admit there are implementation issues that could be very
problematic. :)
Mar 01 2002