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

"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?

"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

"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
>
>
>
>
>
>
>

"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. :)