Re: The Failure of OOP
From: christopher diggins (cdiggins_at_videotron.ca)
Date: 04/14/04
- Previous message: Calum: "Re: The Failure of OOP"
- In reply to: Calum: "Re: The Failure of OOP"
- Next in thread: Robert C. Martin: "Re: The Failure of OOP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 14 Apr 2004 07:21:36 -0400
"Calum" <calum.bulk@ntlworld.com> wrote in message
news:c5iu9g$2mm$1@news6.svr.pol.co.uk...
> christopher diggins wrote:
> > Hi Calum, thanks for reporting these results! This is encouraging for me
to
> > see. This helps to support my claim that there are gains to be had when
> > modeling with interfaces as opposed to ABC's. I am currently working on
a
> > matrix test case. Many people seem to be put-off by the Int and NaiveInt
> > example because it appears too degenerate. I am hoping that a matrix
example
> > will be easier to relate to. Thanks again.
>
> It's definitely a good idea to test this further. I think you will get
> very different results depending on how you slice the cake - and you
> could definitely rig something that will show interfaces in your favour.
> But that is obviously not the point.
>
> As I understand things the tradeoffs are:
>
> ABC Interface
> Object size larger smaller
> Pointer size smaller larger
And the following:
- objects that implement interfaces perform bettter than comparable objects
inheriting ABC's when not referenced
- interface pointer size styas constant with regards to the number of
intefaces implemented where ABC's cause an expansion for each inherited
base.
> The problem comes when you have a pointer to an interface, not an
> object. In general, you would expect to have more pointers than
> objects, which means that interfaces could consume more memory. e.g. in
> a matrix class, you would presumably have a vector of INumeric, 8 bytes
> each.
In some scenarios you would have more pointers than objects, but I am not
sure it is a safe generalization. I have used and written many designs that
use objects more than pointers. The other important point is that we need to
compare the number of concrete pointers (which are not impacted in the
proposal) with the number of base pointers. The goal is to allow specific
designs to exist that do not exhibit unacceptable runtime penalties and code
bloat.
> And where would you "own" the numbers themselves, or would they be in a
> seperate array?
This depends entirely on the design of the software. Both approaches are
valid.
> Could you have the facility for an interface to delete
> its object - that is something you could not do with multiple
> inheritance I think.
>
> Calum
I do not see how this would be a problem, an object could simply to provide
an interface IDestructible that provides a destructor as an explicit named
function.
Thanks for your feedback.
-- Christopher Diggins http://www.cdiggins.com http://www.heron-language.com
- Previous message: Calum: "Re: The Failure of OOP"
- In reply to: Calum: "Re: The Failure of OOP"
- Next in thread: Robert C. Martin: "Re: The Failure of OOP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|