Re: multiple inheritance

Shawnk,

thanks for your input. I agree with your arguments and would be glad to
see the rewritten proof. If I did my estimation right, then I think I have a
proposal which will improve the design "towards shared state space".
Looking forward to hear from you

Lebesgue

"Shawnk" <Shawnk@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C47BFB86-F473-46E3-8FE4-B8C5D007091C@xxxxxxxxxxxxxxxx
Lebesque,

Thanks for your patience with the length of my response. Loved the
proposed approach which (for brevity) I'll call the PI (Pseudo
Inheritance) design technique. I recoded and experimented with this
approach this weekend.

Comparing 'PI' to 'MI' (after coding) my executive summary (short form)
of the differences as follows.

----------

1. Top level specification of state space in multiple inheritance

A. The PI design technique is a wrapper for functionality around
pre-existing state space.

B. MI allows (obviously) state and functional (static and dynamic)
inheritance

C. The PI technique offered (by Lebesque) is a 'functional inheritance'
(dynamic component) high cost approach.

D. The approach fails if the inherited state space (static component) is
intrinsic to the target functionality.

2. Therefore - (e.g. Child_cls is Parent_cls and "kind of is" House_cls).

A. Dynamically true
B. Statically false

C. Which is a formal agreement of your phrase '(e.g. A is C and "kind of
is"
B)'.

D. The 'kind of' is a logical marker for the PI non-inheritance of
functional state space.

----------

Since I use MI for 'top level specifications' (as above) my use of PI
would be as a 'functional wrapper'. As a 'functional wrapper' on
pre-existing state space its a good approach if all you needed was a small
wrapping functionality around a pre-existing state space.

I have a follow up to this (post) if it is of interest. It has your code
redone to prove the 2.A, 2.B assertions above. The proff also shows the
severe limitations of C# as a strategic migration tool to factor out
common
code. It brings out in code the 'kind of' (see above) inheritance
architecture flaw in C#.

To restate: The re-write of your code shows the 'statically false'
assertion
in your 'e.g' given in executive summary above. Sort of explains the above
executive summary in code.

Thanks for your thoughtful and insightful input. I haven't used this
approach but to overcome C# limitations (MI in IMHO ) this approach is
pretty handy :-)

Shawnk

PS. Let me know if you want me to post the rewritten proof of your code.

PPS. High cost based on quantitative/qualitative metrics (1) character
count, (2) visual complexity of pass through code and (3) logical
complexity
of pass through code.


.

Relevant Pages

  • Re: multiple inheritance
    ... Top level specification of state space in multiple inheritance ... The PI design technique is a wrapper for functionality around ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: multiple inheritance
    ... 'existing target' functionality and state space. ... There is no instance of 'House' identity due to the lack ... Child m_child_ins; ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Code reuse
    ... You asked specifically about 2 things: Inheritance and Interfaces. ... functionality, rather than functions existing outside of any class. ... re-use the base class and its functionality in each derived class. ...
    (microsoft.public.dotnet.framework.aspnet)
  • New OO module idea - looking for suggestions
    ... I've been working on a module that provides encapsulation, inheritance ... Another key piece of functionality is that when a method is overridden ... perl developer to explore and perhaps even enjoy some of the features ...
    (comp.lang.perl.modules)
  • Re: Modifier mixture
    ... virtual class, but with the virtual class overrides are optional. ... is inherited it exposes that functionality to all consumer classes. ... I'm not sure that inheritance is the best course here. ...
    (microsoft.public.dotnet.languages.csharp)