Board index » delphi » Multiple Inheritance - Feature Request?

Multiple Inheritance - Feature Request?

Disclaimer: This is not intented as a flame war lighter, but a feature
request... ;-)

I've been working on another OO designed system, and ran across a situation
where multiple inheritance (as I understand it) would come in REALLY handy.

In the traditional OO framework, there is the problem domain class and the
persistance class.  When persisting (if there is such a word), the PD class
must either expose all of its' variables to be persisted, or provide a
method to write its' variables out to the persistance class.  If the
persistance class could inherit from both the base persistance class AND the
specific PD class, the resulting object would have "knowledge" of the PD
internals as well as descend from the persistance object.

In short, multiple inheritance would eliminate some unnecessary code from
either/both of the (PD/persistance) classes.

I would like to be able to do the following...

type
  class TFoo(TObject)
  public
    Name: string;
  private
    FFooData: string;
  end;

  class TBar(TObject)
  public
    Name: string;
  private
    FBarData: string;
  end;

  class TFooBar(TFoo, TBar)
  public
    // To show which class takes prescedence
    // for name duplicates, a keyword (derived)
    // or the like would need to be introduced.
    // The compiler could default to the first
    // class listed in the declaration, then the
    // programmer would need to use the
    // derived keyword only to override the
    // default.
    Name: string; derived TBar;
  private
    procedure SaveData;
  end;

{---Later---}

procedure TFooBar.SaveData;
begin
  SaveSomeData(FFooData);
  SaveSomeData(FBarData);
  SaveSomeData(Name); // Would save TBar.Name
end;

One could extend the multiple inheritance paradigm to inherit from many
classes at once...

class TFooBarBob(TFoo, TBar, TBob)
end;

The properties and methods from each of the derived classes would be
available to a descendent of TFooBarBob, and any name conflicts (for
properties) would be handled by classes listed first in order or the
"derived" directive.

Comments?

Eric Hill

 

Re:Multiple Inheritance - Feature Request?


Quote
> multiple inheritance (as I understand it) would come in REALLY handy.

But it's still bad. You can do what you want using interfaces.

Cheers,
Jim Cooper

_____________________________________________

Jim Cooper      jcoo...@tabdee.ltd.uk
Tabdee Ltd      http://www.tabdee.ltd.uk

TurboSync - Writing Palm conduits with Delphi
_____________________________________________

Re:Multiple Inheritance - Feature Request?


Hit the send key too soon.

Quote
> the resulting object would have "knowledge" of the PD
> internals as well as descend from the persistance object.

Generally this is a bad idea anyway. The framework references given a
few days ago show alternatives you might want to consider.

Cheers,
Jim Cooper

_____________________________________________

Jim Cooper      jcoo...@tabdee.ltd.uk
Tabdee Ltd      http://www.tabdee.ltd.uk

TurboSync - Writing Palm conduits with Delphi
_____________________________________________

Re:Multiple Inheritance - Feature Request?


If by framework references you mean the discussion titled 3-Tier Newbie, I
didn't fully understand all that was discussed there.

Do you have a website in mind?  I'd love to hear some good alternatives to a
published set of properties or a streamable procedure.  The integration
between the PD class and persistance class has really been the most harry
(albeit avoided) part of the OO apps I've written.  Mostly I can fiddle with
it and make it work, but I'd like a really good and solid foundation to base
my code on so that I don't have to use any duct tape.  ;-)

Eric

Quote
"Jim Cooper" <jcoo...@tabdee.ltd.uk> wrote in message

news:3BFBF0CD.64D04D41@tabdee.ltd.uk...
Quote

> Hit the send key too soon.

> > the resulting object would have "knowledge" of the PD
> > internals as well as descend from the persistance object.

> Generally this is a bad idea anyway. The framework references given a
> few days ago show alternatives you might want to consider.

> Cheers,
> Jim Cooper

> _____________________________________________

> Jim Cooper      jcoo...@tabdee.ltd.uk
> Tabdee Ltd      http://www.tabdee.ltd.uk

> TurboSync - Writing Palm conduits with Delphi
> _____________________________________________

Re:Multiple Inheritance - Feature Request?


Quote
"Eric Hill" <e...@ijack.net> wrote in message news:3bfbe388$1_2@dnews...
> method to write its' variables out to the persistance class.  If the
> persistance class could inherit from both the base persistance class
AND the
> specific PD class, the resulting object would have "knowledge" of the
PD
> internals as well as descend from the persistance object.

I won't dispute the MI has occasional worthwhile uses (though I haven't
missed it myself), but domain objects with knowledge of and dependencies
on the persistence mechanism is on my list things to *avoid* in
designing persistence mechanisms and domain objects.

--
[ Kyle Cordes * k...@kylecordes.com * http://kylecordes.com ]
[ Consulting, Training, and Software development tips and   ]
[ techniques: Java, Delphi, ASTA, BDE Alternatives Guide,   ]
[ JB Open Tools, EJB, Web applications, methodologies, etc. ]

Re:Multiple Inheritance - Feature Request?


So how do you implement the path between the PD and storage object?  What
gets transferred and how?  I'm trying to figure out a *reliable* elegant
solution.  What I've done so far works, but I'd like to have something a
little less kludgy.

Eric

Quote
"Kyle Cordes" <k...@kylecordes.com> wrote in message

news:3bfbfec7_2@dnews...
Quote
> "Eric Hill" <e...@ijack.net> wrote in message news:3bfbe388$1_2@dnews...

> > method to write its' variables out to the persistance class.  If the
> > persistance class could inherit from both the base persistance class
> AND the
> > specific PD class, the resulting object would have "knowledge" of the
> PD
> > internals as well as descend from the persistance object.

> I won't dispute the MI has occasional worthwhile uses (though I haven't
> missed it myself), but domain objects with knowledge of and dependencies
> on the persistence mechanism is on my list things to *avoid* in
> designing persistence mechanisms and domain objects.

> --
> [ Kyle Cordes * k...@kylecordes.com * http://kylecordes.com ]
> [ Consulting, Training, and Software development tips and   ]
> [ techniques: Java, Delphi, ASTA, BDE Alternatives Guide,   ]
> [ JB Open Tools, EJB, Web applications, methodologies, etc. ]

Re:Multiple Inheritance - Feature Request?


Quote
> "Kyle Cordes" <k...@kylecordes.com> wrote in message
> > missed it myself), but domain objects with knowledge of and
dependencies
> > on the persistence mechanism is on my list things to *avoid* in
> > designing persistence mechanisms and domain objects.
"Eric Hill" <e...@ijack.net> wrote in message news:3bfc03b3_2@dnews...
> So how do you implement the path between the PD and storage object?

What

A good starting point is here:

http://c2.com/cgi/wiki?HexagonalArchitecture

with vital background information here:

http://c2.com/cgi/wiki?DependencyInversionPrinciple

The key is that the domains objects are the core of the system, so it
makes sense to have other code depend on them, but *not* them depend on
other code.  So to answer your question in a more direct way, the domain
objects should expose whatever features are needed for something on the
outside (such as a persistence mechanism) to work with them.  Note that
they might expose a difference interface (in the literal or figurative
sense) to the persistence mechanism than they do to the other code.

It's also possible that an abstract notion of a persistence mechanism
becomes part of the domain object module(s) - so the domain object would
know how to tell the persistence mechanism that it's "dirty", but still
have no dependency on the concrete persistence mechanism which responds
to that fact.

By the way, having domain objects which aren't bound to the persistence
mechanism also makes it much easier to test them.

--
[ Kyle Cordes * k...@kylecordes.com * http://kylecordes.com ]
[ Consulting, Training, and Software development tips and   ]
[ techniques: Java, Delphi, ASTA, BDE Alternatives Guide,   ]
[ JB Open Tools, EJB, Web applications, methodologies, etc. ]

Re:Multiple Inheritance - Feature Request?


In article <3bfbe388$1_2@dnews>, Eric Hill says...

Quote
> Disclaimer: This is not intented as a flame war lighter, but a feature
> request... ;-)

> I've been working on another OO designed system, and ran across a situation
> where multiple inheritance (as I understand it) would come in REALLY handy.

What about using interfaces instead? I guess that is the classical
Object Pascal answer.
--
Rudy Velthuis (TeamB)

Re:Multiple Inheritance - Feature Request?


"Rudy Velthuis (TeamB)" <rvelth...@gmx.de> skrev i melding
news:MPG.16662811bcb5be0c98b615@newsgroups.borland.com...

Quote
> In article <3bfbe388$1_2@dnews>, Eric Hill says...

> > Disclaimer: This is not intented as a flame war lighter, but a feature
> > request... ;-)

> > I've been working on another OO designed system, and ran across a
situation
> > where multiple inheritance (as I understand it) would come in REALLY
handy.

> What about using interfaces instead? I guess that is the classical
> Object Pascal answer.

Yes, but it only solves one of the problems, the one about "compatibility".
An interface means no code, so you'll have to a) duplicate code or b) using
delegation. In the latter case it may be solved by a helper class *without*
interfaces.
Don't get me wrong, interfaces *are* powerful as part of OOP.

--
Bj?rge S?ther
bjorge@hahaha_itte.no

Re:Multiple Inheritance - Feature Request?


Quote
> Do you have a website in mind?  

Try this one for starters:

http://martinfowler.com/isa/index.html

Cheers,
Jim Cooper

_____________________________________________

Jim Cooper      jcoo...@tabdee.ltd.uk
Tabdee Ltd      http://www.tabdee.ltd.uk

TurboSync - Writing Palm conduits with Delphi
_____________________________________________

Re:Multiple Inheritance - Feature Request?


In article <3bfc2d4c_1@dnews>, Bj?rge S?ther says...

Quote
> > What about using interfaces instead? I guess that is the classical
> > Object Pascal answer.

> Yes, but it only solves one of the problems, the one about "compatibility".
> An interface means no code, so you'll have to a) duplicate code or b) using
> delegation. In the latter case it may be solved by a helper class *without*
> interfaces.
> Don't get me wrong, interfaces *are* powerful as part of OOP.

The "implements" keyword helps you with the implementation as well.
--
Rudy Velthuis (TeamB)

Re:Multiple Inheritance - Feature Request?


"Wayne Niddery [TeamB]" <wnidd...@aci.on.ca> wrote in message news:3bfc53ce$1_2@dnews...

Quote
> "Eric Hill" <e...@ijack.net> wrote in message news:3bfbe388$1_2@dnews...
> Any members of the PD class that need to be persisted should be public
> anyway

Why this ?

Cheerio
Radek

Re:Multiple Inheritance - Feature Request?


On Fri, 23 Nov 2001 13:17:44 +0100, "Radek Jedrasiak"

Quote
<NNNOOOe9327...@student.tuwien.ac.atSSPPAAMM> wrote:

>"Wayne Niddery [TeamB]" <wnidd...@aci.on.ca> wrote in message news:3bfc53ce$1_2@dnews...
>> "Eric Hill" <e...@ijack.net> wrote in message news:3bfbe388$1_2@dnews...
>> Any members of the PD class that need to be persisted should be public
>> anyway

>Why this ?

How to you access them otherwise without implementing a interfaced
method or public method into the PD which viaolates the rule that the
PS should be transparently made peristent to different media. (unless
you use the BLOB approach of streaming anything into a single field)

Regards from Germany

Franz-Leo

Re:Multiple Inheritance - Feature Request?


Quote
"Franz-Leo Chomse" <franz-leo.cho...@samac.de> wrote in message news:tcjsvtorlpgci8nl9naslbiorr1s210g9i@4ax.com...
> On Fri, 23 Nov 2001 13:17:44 +0100, "Radek Jedrasiak"
> <NNNOOOe9327...@student.tuwien.ac.atSSPPAAMM> wrote:

> >"Wayne Niddery [TeamB]" <wnidd...@aci.on.ca> wrote in message news:3bfc53ce$1_2@dnews...
> >> "Eric Hill" <e...@ijack.net> wrote in message news:3bfbe388$1_2@dnews...
> >> Any members of the PD class that need to be persisted should be public
> >> anyway

> >Why this ?

> How to you access them otherwise without implementing a interfaced
> method or public method into the PD which viaolates the rule that the
> PS should be transparently made peristent to different media. (unless
> you use the BLOB approach of streaming anything into a single field)

You're of course right, in the "limited" world of Object Pascal.

But i don't see any reason why *all* persisted data should be
public in general. It's just something we have to live with because
we don't have RTTI for non published members.

Cheerio
Radek

Re:Multiple Inheritance - Feature Request?


Quote
>But i don't see any reason why *all* persisted data should be
>public in general. It's just something we have to live with because
>we don't have RTTI for non published members.

No thats normal encapsulation. Everything less than public can
only be used by descendants.  

The level is public not published!.

Regards from Germany

Franz-Leo

Go to page: [1] [2]

Other Threads