multiple inheritance

[Mark]

why doesn't .NET support multiple inheritance?
I think it's so silly!

Cheers,
Mark

[Radek Cerny]

Joanna,
no, I need MI. Have you ever had a decent MI platform to develop on? I
"think" and design (well used to anyway) relying on MI. Unfortunately, I
had tremendous success with this. I decomposed the world into objects with
a few different "base" types. I could combine these at will and achieve
amazing things at minimal time/effort (eg cost). If I could show you my
world you would be convinced that MI is necessary.
If it were not for this thread, the self-brainwashing would have worked.
Now I'll need therapy again.
Bugger.

"Joanna Carter [TeamB]" <jo****@not.for .spam> wrote in message
news:u4******** *****@TK2MSFTNG P09.phx.gbl...

"Radek Cerny" <ra*********@NO SPAM.c1s.com.au > a écrit dans le message de
news: ek************* *@TK2MSFTNGP09. phx.gbl...

| Thanks. I feel much better too. I knew I wasnt alone. I grew up with
MI
| and miss it dearly in .NET. Only today to I find myself COPYing code
into
a
| few places because interfaces just cant do what I need.

Sounds to me you need to use interface implementation by delegation - a
much
better paradigm than MI.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Joanna Carter [TeamB]]

"Radek Cerny" <ra*********@NO SPAM.c1s.com.au > a écrit dans le message de
news: %2************* ***@TK2MSFTNGP1 1.phx.gbl...

| no, I need MI.

I would contest that one of the things that is the matter with you is that
you think there is nothing the matter with you. :-)) (sort of quote from
R.D.Laing)

| Have you ever had a decent MI platform to develop on?

Yes, I used to use C}}, but then I saw the one true light of interfaces :-)

It really is tha same animal under a different skin. You can design your
classes justr as before, the only difference is that when you want to
combine multiple base classes, you declare an interface for each class and
implement those multiple interfaces in one class by delegating to composite
instances of the other "derived" classes in that sub-class.

| Now I'll need therapy again.

Just keep chanting "C# is good" :-)))

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Shawnk]

Joanna,

Thank you so much for this excellent suggestion. Also thanks for earlier
responses to my posts.

I use a 4-5 participant EOP (Event Observer Pattern) that is just delegate
based.
Pattern artifiacts (major and most common ones)

1. Delegate type (Signature)
2. Delegate instance
3. Delegate Method
4. Event Method
5. Binder Method

Pattern roles

1. Subject
2. Observer
3. Binder
4. Client
5. Monitor

The Subject (subscribe/unsubscribe), Observer (attach,unattac h) binder
methods allow a fairly wide range of bind processes.

I must agree that the EOP is one of the most fundamental and 'new' forms of
expression. I use it in 'self assembling' container objects that, when passed
to a pattern generator, can assemble themselves into a 'pattern instance'. An
example is a data composition/decomposition pipeline with multiple 'event
stages' (the pattern instance) that are tied to typed event channel (the
backbone of the data flow through the various stages).

Yet, with all due respect, patterns are in vogue and remind me of expert
systems in the 1980s in the industrial/military startup high tech community.
Expert systems turned out the be not as fundamental as originally perceived
(case in point the rule engine in Biztalk - runs a process - not the company
:0)

MI allows a call tree to 'travel' (or expand - take your favorite semantic
term) vertically or horizontally in a stratified system diagram.

Many people only envision call trees in a vertical dimension of a stratified
system diagram (ie. ISO 7 layer OS, SOA 3->7 layer systems).

With MI, however, call trees can branch horizontally through several calls,
such as in business logic (SOA-3L). Thus the call tree moves 'horizontally'.

For those engineers who can turn a collection-with-cursor diagram from
vertical into a horizontal turing machine the MI argument seems pretty plan.

MI approaches an almost numeric/mathematical fundamental level with Von
Nueman 'turing machines'. Its general nature can be envisioned in a
fundamentally more primal category of computing patterns then say an EOP.

I've programmed (real world projects succefully delivered) in HLDV
(hardware/chips/simulators), microcode, assembly, POST(RAS), several high
level languages. I have also done nueral nets, expert systems, supercomputers
and natural language processing (I hop technologies every 2 or 3 contracts if
not every one).

I may be missing something but I still have to go on my own belifes,
experience and (especially) code output.

LLP (Low level patterns - artifact tagging - _ptr, etc) show pretty
conclusively (in my code base) that EOP and other 'funamental core C#
patterns (reflection probe patterns, interface drivers, etc) are a conceptual
level above MI.

With MI the turing tape (of the Turing machine) can be wound out (without
break) along the L1-Lx complexity stratification AND the F1->Fx functional
partitioning. Furthermore the path of the tape head (Turing Machine Pattern)
can be represented as a clockwise/counterclockwis e single complete path on
any Lx using a pie chart of F1->Fx (but you have to contrive a reordered set
of pie slices for each instance of a functional call path - in the call tree).

In rebuttal one could present the EOP event stream as a turning machine. But
this proves that EOP inherently provides no complexity breakdown mechanism
(such as with L1->Ln and F1-> Fn. Without formally modelled dimensions of
complexity breakdown (such as in the dimensions L and F) the EOP becomes just
a simple turing machine.

Decorated backbones (of the event channel) could be presented as a
complexity breaddown mechanism. This is a conceptual error however as event
channel data type (the most common use of backbone typing) is a 'data flow'
mechanism for 'data flow typing' (base class EventArgs). IMHO - The staged
pipeline pattern is peer to (say) the collection residence pattern
(collections with assignable write iterators).

Note I'm on the edge of the EOP pattern domain and not discussing
selfbinding contrived examples of 40 lines of code (which are great and
wonderful solutions for many applications - we all have to 'draw from the hip
ocassionally).

I always appreicate your excellent thoughts on these matters and the EOP may
be more fundamental than I realize. However my passing interest in runtime
pattern generators for automated data composition is in LLP format. The LLP
groupings (artifact sets for EOP, Reflection, state machines) tends to prove
the hypothetical existance a more fundamental CPG 'Composition Process
Generator' of which the EOP is one of many target implemenation results (to
implement the data composition itself).

Summary point is if I had to write and deliver a CPG 'on contract' (money
says it all :-) I wouldn't touch it without MI. Since C++ is getting a little
slow productivity wise I'd pass on the project and do more interesting things
until I can find a C# replacement.

IMHO - A C# replacement is inevitable (for Von Nueman computing approaches -
VS say nueral nets (perception/actuation) and other 'niche' technologies).
(Also I have the most wonderful respect - and especally thanks - to
Anders_and_team for making programming such a wonderful and elegant
experience)

IMHO - An informal proff of the C# demise (assuming no MI in C#) could be
done with a cup of coffee, and maybe a beer. The proff would be to find the
most fundamental TMP (Turing Machine Pattern) expressed in the C# 'challenger
pattern'.

The 'challanger pattern' proves C# does not need MI.

I deeply respect your posts and thoughts (not just on my posts) and would be
very interested to see you come up wth an EOP based informal proff that WAS
not (fundamentally proved to be) a backbone decorated dataflow.

If you have already done an informal 'challenger pattern' (proves MI not
needed in any language - let alone C#) could you post it here for all of us
interested in MI?

Please forgive me if this post is too obtuse. With my limited time I can say
so much more with simple logical thought patterns than C# code examples.

Thank you again for you excellent suggestion on EOP. I always enjoy your
comments.

Shawnk


"Joanna Carter [TeamB]" wrote:

Sounds to me you need to use interface implementation by delegation - a much
better paradigm than MI.

Joanna

[Shawnk]

Joanna,

I hope I have not misunderstood you excellent EOP solution.

I may be wrong about the following so please correct me.

In MI there is NO COMPOSITE code artifiacts (embedded classes performing the
F1->Fx), NO INTERFACE IMPLEMENTATION. The base classes are 'passed right
through' to the client (user of the class based on an MI integration approach
to build a composite). The 'pass through' artifact result of MI is what give
the coding utility to F1-Fx as base classes B1-Bx.

So as a character count based formal proff, in MI the ':', ',',
'each_bas_cls[1->x] is the quantified (numeric) focal point of the proff.

With C# the order of magnitude expression is 2 to 4 oders of magnitude
larger. Note the is an 'off the cuff' formal proff. Better formal proffs
(quantified) can be obtained using a 'cross pollenation' approach and
concentric circles on the functional pie chart (with in the Ln stratification
level). These additional proffs would make the MI focal point (the class
using MI) a USER/CLIENT of the F1->Fx presented by the base class set.

At first glance the COMPOSITE expression of C# and MI seem identical in
order of magnitude quantifier metrics. However when the base class set itself
used MI the argument falls flat because of the recursiver nature of the
quantites invloved.

If we contain our (present) discussion space to a quanified character
count.... how can you propose C# as a logicall expression medium with equal
to or less information (characterwise) .

Note I have bypassed the 'intellectual - time' burdern of have to read and
absore the additional code lines of the composite aggregation (in C# - as in
code maintance, refactoring, etc).

So, am I (we) wrong? Based on character count? (so we remain somewhat
professional and not religious).

I have 14 years of experience coding with C++ but still, experience pales in
comparions with raw intellect (Mozart, Enstein) and, being a regular joe
coder, I'm always learning from the excellent posts in this newsgroup.

Thank you ahead of time for your response. I really like to hear your take
on this in case I'm wrong or have missed something.

Shawnk

Yes, I used to use C}}, but then I saw the one true light of interfaces :-)

[Ian Semmel]

Q Does C# have multiple inheritancy ?
A No

Sort of ends the argument
Shawnk wrote:

Mark,

You are right. It is silly but more more importantly it severly limits the
ability to combine, in an articulate and elegant manner, functionally
orthogonal processing.

My take on the manner is that 'closed communities' tend to be intellectually
sterile (see summary statement).

In spite of the excellent professionalism of the C# programming community
and the significant contributions of C# (reflection, LINQ, EOP (Event
Observer Pattern)) the core decision making of C# architecture is very, very
small (God Bless Anders!!!).

The argument aganist C# MI (Multiple Iheritance) deals with complexity.

The complexity they speak of is mostly the implementation 'under the covers'
complexity. Of secondary import (in arguments aganist) is the supposed
'complexity' of expression (above the covers). I will drop 'under the covers'
issues and focus on the 'above the covers' issue of WHY (IMHO) MI (multiple
Inheritance) as been rejected by the closed community.

Q. WHY is MI not in C#?
A. Expression complexity

Expression complexity (for lack of a better term) is a most shallow argument
aganist the inclusion of multiple inheritance. When I say 'expression
complexity' I DO NOT MEAN a 30 line contrived example. I mean the 'expressive
complexity' on the order of millons of lines of code, similar in scope to
Lord of the Rings and Sherlock Holmes (If you can't make the leap don't read
further).

Currently in C# we divide and conquer complexity by (1) stratification in
(A) call levels and (B) inheritance. So complexity can be 'layered' from L1
to Ln. Single inheritance can be fitted to the concept of just being another
layer - Li.

In C++ we also have multiple inheritance to divide and conquer complexity by
(2) functionally orthogonal articulation. Thus any Lx (level of
stratifaction) can contain F1 to Fn. So a single class 'inherits' F1 to Fn as
multiple classes via MI. Now the derived class can call embedded classes (the
next LX) and also call or provide (to a caller) F1 to Fn.

SI as Li VS MI as F1 - FN is the core 'sticking point' that divides the
FOR/AGANIST campes.

WHY : THOSE OPPOSED TO C# MI : They say an Lx with F1 -> Fx is to complex.

Their summary statements always say something like 'not worth it' meaning it
brings in more problems than not.

I would tend to agree if every Lx (Level of stratification) had a functional
break out (More than one Fx via more than one parent class via MI). BUT -
IMHO - only 10 to 30 % (a hip shot I admit) of levels in a 'real world'
design have a 'functional breakout'. So I think that MI for functional
decomposition is hetrogenous (and clustered on a few key levels a real world
component design) and not homogenous.

I love MI (Multiple Inheritance). It ONLY simplifies things (above the
covers). More importantly, I believe that a simple implementation (under the
covers) is inherently doable (if I wrote the compiler - I love saying that!
:-). But the core dev team of C# does not (so much for MHO :-)

[BTW - Pipelining and OOA (Object Oriented Approach) do not result in a
'single top node' simplification via language feature sets. Multiple
inheritance, for example, is a code element mechanism that formally produces
a functional focal point (the derived class access and 'pass through' of
multiply inherited function).]

I have the deepest respect and admiration for the Anders/C#Community of
thougth. But I truly believe another solution, post C#, will fill the
programming void of the future caused by this significant and unfortunate
expressive hole (in the fundamental C# architecture).

I think the 'intellectual sterility' (flame me please - I'm asking for it
:-O) resides in the tendency to determine everything (language feature wise)
in a 30 to 40 line contrived example IN C#.

As Einstein said you have to go at least one level 'above' something to talk
about it. So system level arguments (Lx + FX combined as a single point
(classs) via MI) do not carry much weight because they are 'above' that 30 to
40 line intellectual prison of many core community members (MVPs, etc).

So -IMHO - the 'closed community' is formed by the 30 to 40 line mindset.
Like Republican/Democrat dialogs your 'camp' is defined by your values and
comfort zone. Its always nice to know I'm not alone in my 'camp'.

Good luck to you Mark. It's (also) always nice to know someone else is
sharing my pain :-)

shawnk

PS. It always feels 'so good' to get this off my chest. Thanks for the
opportunity.
"Mark" wrote:

why doesn't .NET support multiple inheritance?
I think it's so silly!

Cheers,
Mark

[Joanna Carter [TeamB]]

"Shawnk" <Sh****@discuss ions.microsoft. com> a écrit dans le message de news:
98************* *************** **...icrosof t.com...

| Please forgive me if this post is too obtuse. With my limited time I can
say
| so much more with simple logical thought patterns than C# code examples.

Well, I have to be honest and say that I didn't understand more thatn a
couple of sentences of what you wrote, but then I am more interested in real
world architecture and design than the theoretical science of it :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Arnaud Debaene]

Shawnk wrote:

Mark,

You are right. It is silly but more more importantly it severly
limits the ability to combine, in an articulate and elegant manner,
functionally orthogonal processing.

My take on the manner is that 'closed communities' tend to be
intellectually sterile (see summary statement).

<snip>

I read and (tried to) understand your excellent mathematical demonstration,
and if I was the only one to work on my projects, I would mostly agreed.

Alas, in real world, there is one single word that play against your whole
demonstration : maintainability .
I have yet to see a real-world MI based architeture that is easily
understandable : I have worked with various such models, in C++, and all
failed their promises because the initial design, sound as it may have been,
had been wasted by subsequents evolutions.

The only exception that comes to my mind being ATL/WTL (that is still
considered too complicated by many managers), but there MI is highly
integrated with templates - AKA the "curiously recurring template pattern",
and is is not "pure" MI modelisation.

Arnaud
MVP - VC

[Steven Nagy]

>> Q Does C# have multiple inheritancy ?

A No
Sort of ends the argument

I don't think that was ever the argument at all.
Check out the OP's post. They already knew that it didn't support MI.

This whole conversation comes around to this thread about once a month,
maybe more.
I'd be interested to know if the same people post each time...

[Shawnk]

Arnaud,

Both are execllent and valid points.

Point 2 : I've seen good architectures with MI. They tend to use vertical
stratification as a 'main trunk' and then 'branch horizontally' using MI.
IMHO - The key to good MI results its using it the create 'functionally
orthogonal' computing blocks. For this you need a 'natural programmer' who
has an inherent gift that prevents the 'functional confusion and chaos' you
mention. Since my experience and you experience differ it would make sense we
differ on the utility of MI.

Point 1 : I think maintainability is dependent on architecture. With the
advent of namespaces I believe that Inherent, functionally orthogonal designs
can be formally proven using API call domains expressed as name spaces.
Independent of this, the design architect really should show the main
architecture visually (personal opinion). The design 'artwork' is what I look
for in truly gifted software engineers but its not all that common.

New point : Quantified metric of MI AND Interfaces.

I always see MI and Intefaces as complimentary. I love them both.

A Quantified metric of functional dispersion and cross pollenation can be
developed by centering on the focal poinst (of MI and Interfaces) and looking
at the immediate upstream (towards parents) classes. For each Base B_cls
total the namespace points. This creates a 'Functional Dependency' (FD)
structure based on platform API calls.

You then come with a 'Dispersion Index' on a per namespace basis. (Say a
simple count of classes that use a target namespace). You run a 'Dispersion
Probe' which tunnels through FD structure and creates a Dispersion Index for
each namespace (in the list of namespaces used - Note - each 'namespace' is
really the namespace path with terminal point containing the used API call).

Finally you order the Dispersion Array (list of namespace points) according
to Dispersion Index depending on if you want to find the worst functional
dispersion (used in most base classes) or the best functional focus.

Looking at the worst functional (most commonly used everywhere) function
points you can usually find which candidates should really be in seperate
stratification level. You can also find candidates for refactoring along
functionally orthogonal lines within the domain of any Lx (stratifcation
level).

Finally : The operation can be performed on both MI and Interface designs to
measure functional dispersion and orthogonality.

With the introduction of namespaces in C# I think a natural result is just
such a metric. It would, historically, be similar to the Macabe metric of
axomatic complexity for call paths (I may have a spelling error on the name).

Summary : You, as did Joanna, hit the key purjorative point on MI (assuming
character count proffs do show MI to be more powerful from a functional
agregation point of view).

I sitll believe the demise of C# is inevitable for the above reasons and
will unfold in the future market space history for the above reasons. But
this is conjecture. Our mutual interest and set of logic points both have an
interest in this type of metric analysis (functional dispersion patterns in
MI and Inheritance). Hopefully our community will rise to the challenge some
day and produce a nifty free tool on www.snapfiles.com (or whatever) to help
all programmers produce better code faster.

Thank you for your two excellent points. Along with the expression burden
(Character count different between functional integration/aggregation of MI
and Interface expressions) they provide important clues to a quantified
solution to this seemly intractable problem.

Shawnk

Point 1 : > Alas, in real world, there is one single word that play against
your whole

demonstration : maintainability .
Point 2 : > I have yet to see a real-world MI based architeture that is
easily understandable :

[Shawnk]

I've worked directly with a number of fellows and principle scientists and
there is no 'inherent' difference between theory and science. LINQ is an
'envelop point' of the current state of art in progamming language. One day
it will be a ubiqutous assumption of platform code used by expressive
techniques in the future.

Quantifiable metrics are the meeting point of both. ALL the top people I
work with talk like this. All of them. They all tailor content and
articulation per audience which is what makes them successfull in the
executive realm (operations/management) as well (thus the obtuse indicator).
Also coding up a metric analyzer is (often ) not that difficult - you just
need the time (something, I admit, we all lack).

Summary point : Theory and Science CREATE real world architecture.

I would like to think that the C# community in this newgroup has enough
range for both newbies and theory since all of us are newbies in many areas
while being quite proficient in others.

I wanted to thank you for your comment with this post and also encourage any
other community members who are interested in future architecture within C#
to discuss some of the (admittedly) theorical points to better articulate the
architecture features found in future versions of C#.

I would also like to think that some of the community discussion (on theory)
is helpful to Anders and his dev team.

Thank you again for you input.

Shawnk

PS. A case in point is Arnaud Debanee's point on maintainabilty. Giving an
exploratory rebuttal to his concerns helps to articulate (read that - make it
real world and not just some cheap jerk off polemic) potential (though
informal) proffs that can help the community with new ideas. Thank you again
for clarifying your interest regarding the intersection of real world
architecture and computing theory.

"Joanna Carter [TeamB]" wrote:

"Shawnk" <Sh****@discuss ions.microsoft. com> a écrit dans le message de news:
98************* *************** **...icrosof t.com...

| Please forgive me if this post is too obtuse. With my limited time I can
say
| so much more with simple logical thought patterns than C# code examples.

Well, I have to be honest and say that I didn't understand more thatn a
couple of sentences of what you wrote, but then I am more interested in real
world architecture and design than the theoretical science of it :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer