Strategic Functional Migration and Multiple Inheritance

I guess all of us MI proponents stopped even dreaming when Anders uttered
those words "MI? Over my dead body!".

I miss MI dearly and would forego any and all other .NET improvments to have
it.

Cheers

"Shawnk" <Sh****@discussions.microsoft.com> wrote in message
news:81**********************************@microsof t.com...

Nicholas,

Thank you for your response.

The numbers in points [1] and [2] are completely contrived.

We wanted to articulate the difference between (1) understanding and (2)
use
of II (Implementation Inheritance). We also wanted to establish a metric
level for
change (by evolution, user migration to other languages, user loyalty (as
in
C++)) that would account for the lack of MI (Mulitple Inheritance) in
recent
language offerings (java, C#, D++).

The metrics of 'less than 1%' seemed to be a reasonable way to account for
the apparent 'level of interest' (lack of interest) in MI/SFM among
'expert'
and 'senior' level programmers in the non-C++ programming communities.

As to 'why MI is not supported' - the lack of interest or the response to
this post is an indication that verifies (informally) the 'less than 1%'
water mark. And yes, ... it appears that the II, MI and SFM are not
used/understood/desired in the non-C++ programming communities :-)

We wanted to post this question in several language communities prior to
any
other actions (such as recommendations, etc). Also, making recommendations
would be distracting to an audience/community that has no
interest/understanding/desire of the utility of MI/II/SFM.

Your good point about a recommended design implementation for MI in C++
(in
my mind) is really hinged/connected to Anders position of 'no MI in C#'.
Since all the videos, interviews, etc. (That I have seen) indicate he has
NO
interest in MI/II/SFM it is reasonable to assume that C# will always be a
less expressive (relative to functional orthogonality) and powerful
language
compared to C++.

Note that C# is an excellent language and wonderfully expressive from a
productivity standpoint (type safety, etc). Its current contribution via
LINQ
is excellent as its historic introspective (reflection) and binding
(delegates,events) mechanisms. As a mechanism for automated pattern
detection
and refactoring it fails (IMHO) because of the importance of functionally
orthogonal mechanisms (such as MI/II/SFM, etc).

The lack of use of .NET in the Microsoft Vista implementation is something
of interest (to the MI/II/SFM issues) that we will pursue (as opposed to
C#
recommendations) to get a feel for MI/II/SFM issues in various programming
communities.

Thanks again for your input.

Shawnk

PS. The lack of MI/II/SFM in .NET is a basic, serious and fundamental flaw
(IMHO) of the 'operating system' (as in .NET) itself. This, of course,
hinges
on the validity of point [3] which is the basis for Ander's position on MI
in
C#.
"Nicholas Paldino [.NET/C# MVP]" wrote:
I would be interested in knowing how you came to the numbers that you
have in points 1 and 2.

While I agree that implementation inheritance would be useful, if the
numbers that you claim are anywhere near correct, you have already
answered
why MI is not supported in modern languages (meaning most .NET languages,
Java).

In all of this, I didn't see a recommendation on how such
functionality
might be included in C# (proposed language syntax, rules, etc, etc). Why
not show something of that nature?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Shawnk" <Sh****@discussions.microsoft.com> wrote in message
news:37**********************************@microsof t.com...
> Some Sr. colleges and I have had an on going discussion relative to
> when
> and
> if
> C# will ever support 'true' multiple inheritance.
>
> Relevant to this, I wanted to query the C# community (the 'target'
> programming
> community herein) to get some community input and verify (or not) the
> following
> two statements.
>
> [1] Few programmers (3 to7%) UNDERSTAND 'Strategic Functional Migration
> (SFM)' (see PS below).
>
> [2] Of those few, even less (another 3 to 7%) are GOOD at Strategic
> Functional Migration (or 0.9% to 0.49%).
>
> Do these percentages seem about right? (less than 1% of the target
> programming
> community are GOOD at SFM)
>
> Thanks ahead of time for any relevant QUALITY input.
>
> Shawnk
>
> PS.
>
> Strategic Functional Migration (SFM) is described in the post following
> this
> one.
>
> PPS. I submit to my fellow colleges that the answer (point spread)
> determines
>
> [A] Short term mitosis of the few to pioneer a new language
> incorporating
> C#
> productivity with C++ (SFM) powers
>
> [b] Long term community evolution and industry migration away from C#
> as a
> 'core competency' solution (subtle point)
>
> Both A/B, in turn, instantiate the 'early adopter' model in the
> compiler
> market.
>
> PPPS.
>
> I have a 'core competency' project I want to do that would be a lot
> easier
> if I
> could use SFM with C#.

Jun 5 '06 #6

Shawnk

Thank you for letting me know of Anders 'Over my dead body' statement.

I have secretly harbored a suspicion that Java (and lately C#) is inherently
'evil' because there is 'No Multiple Inheritance'. With Anders' statement
above I
now KNOW C# is inherently evil.

......

And if C# IS inherently evil, AND today IS 6/6/6 (666), .... we MUST
consider the
possibility that Anders as actually .... evil incarnate masquerading as a
'being of
light' :-)

All of that great stuff (reflection, events, generics, LINQ) was actually
an EVIL FACADE to force us to live without MULTIPLE INHERITANCE.
(I see it all now !!!).

And since Anders IS such a wonderful and likeable guy (just a clever
masquerade) it all makes sense!

Strange as it may seem I had a dream (nightmare) last night in which
Anders played a flute leading the world's programmers to the 'Gates' of hell.
As I entered the gate turned into a couple of giant legs.

I looked up an there was Bill 'Gates' as the devil (which makes Anders just a
subservient demon) shouting 'No Multiple Inheritance for .NET' and then he
laughed wickedly.

The C# development team all had firery tridents and keep prodding the
incoming programmers
into teeny tiny cubicles. The C# Experts and MVPs walked on walls just above
the cubicles
with whips and threatened code reviews.

And finally I saw Jon Skeet himself sitting on a high platform beating a big
drum saying to each beat..

- No
- Multiple
- Inheritance
- No
- Multiple
- Inheritance
......

Suddenly .. - I woke up in a cold sweat and couldn't get back to sleep
without the light being on.

.......

Interesting how synchronisity and occult insights work on these new age date
kind of things :-)

Thanks for the comment :-)

Shawnk

PS. Of course it could have been the anchovy pizza....

"Radek Cerny" wrote:

I guess all of us MI proponents stopped even dreaming when Anders uttered
those words "MI? Over my dead body!".

I miss MI dearly and would forego any and all other .NET improvments to have
it.

Cheers

"Shawnk" <Sh****@discussions.microsoft.com> wrote in message
news:81**********************************@microsof t.com...
Nicholas,

Thank you for your response.

The numbers in points [1] and [2] are completely contrived.

We wanted to articulate the difference between (1) understanding and (2)
use
of II (Implementation Inheritance). We also wanted to establish a metric
level for
change (by evolution, user migration to other languages, user loyalty (as
in
C++)) that would account for the lack of MI (Mulitple Inheritance) in
recent
language offerings (java, C#, D++).

The metrics of 'less than 1%' seemed to be a reasonable way to account for
the apparent 'level of interest' (lack of interest) in MI/SFM among
'expert'
and 'senior' level programmers in the non-C++ programming communities.

As to 'why MI is not supported' - the lack of interest or the response to
this post is an indication that verifies (informally) the 'less than 1%'
water mark. And yes, ... it appears that the II, MI and SFM are not
used/understood/desired in the non-C++ programming communities :-)

We wanted to post this question in several language communities prior to
any
other actions (such as recommendations, etc). Also, making recommendations
would be distracting to an audience/community that has no
interest/understanding/desire of the utility of MI/II/SFM.

Your good point about a recommended design implementation for MI in C++
(in
my mind) is really hinged/connected to Anders position of 'no MI in C#'.
Since all the videos, interviews, etc. (That I have seen) indicate he has
NO
interest in MI/II/SFM it is reasonable to assume that C# will always be a
less expressive (relative to functional orthogonality) and powerful
language
compared to C++.

Note that C# is an excellent language and wonderfully expressive from a
productivity standpoint (type safety, etc). Its current contribution via
LINQ
is excellent as its historic introspective (reflection) and binding
(delegates,events) mechanisms. As a mechanism for automated pattern
detection
and refactoring it fails (IMHO) because of the importance of functionally
orthogonal mechanisms (such as MI/II/SFM, etc).

The lack of use of .NET in the Microsoft Vista implementation is something
of interest (to the MI/II/SFM issues) that we will pursue (as opposed to
C#
recommendations) to get a feel for MI/II/SFM issues in various programming
communities.

Thanks again for your input.

Shawnk

PS. The lack of MI/II/SFM in .NET is a basic, serious and fundamental flaw
(IMHO) of the 'operating system' (as in .NET) itself. This, of course,
hinges
on the validity of point [3] which is the basis for Ander's position on MI
in
C#.
"Nicholas Paldino [.NET/C# MVP]" wrote:
I would be interested in knowing how you came to the numbers that you
have in points 1 and 2.

While I agree that implementation inheritance would be useful, if the
numbers that you claim are anywhere near correct, you have already
answered
why MI is not supported in modern languages (meaning most .NET languages,
Java).

In all of this, I didn't see a recommendation on how such
functionality
might be included in C# (proposed language syntax, rules, etc, etc). Why
not show something of that nature?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Shawnk" <Sh****@discussions.microsoft.com> wrote in message
news:37**********************************@microsof t.com...
> Some Sr. colleges and I have had an on going discussion relative to
> when
> and
> if
> C# will ever support 'true' multiple inheritance.
>
> Relevant to this, I wanted to query the C# community (the 'target'
> programming
> community herein) to get some community input and verify (or not) the
> following
> two statements.
>
> [1] Few programmers (3 to7%) UNDERSTAND 'Strategic Functional Migration
> (SFM)' (see PS below).
>
> [2] Of those few, even less (another 3 to 7%) are GOOD at Strategic
> Functional Migration (or 0.9% to 0.49%).
>
> Do these percentages seem about right? (less than 1% of the target
> programming
> community are GOOD at SFM)
>
> Thanks ahead of time for any relevant QUALITY input.
>
> Shawnk
>
> PS.
>
> Strategic Functional Migration (SFM) is described in the post following
> this
> one.
>
> PPS. I submit to my fellow colleges that the answer (point spread)
> determines
>
> [A] Short term mitosis of the few to pioneer a new language
> incorporating
> C#
> productivity with C++ (SFM) powers
>
> [b] Long term community evolution and industry migration away from C#
> as a
> 'core competency' solution (subtle point)
>
> Both A/B, in turn, instantiate the 'early adopter' model in the
> compiler
> market.
>
> PPPS.
>
> I have a 'core competency' project I want to do that would be a lot
> easier
> if I
> could use SFM with C#.

Jun 6 '06 #7

Wow. I love anchovy pizza - never had that as a result. Maybe its all true
and you are psychic.
Its sad how so many otherwise helpful and intelligent people are so anti-MI.
Maybe its what you grow up with and get used to - like having legs, arms and
eyes. If you've never had them, you dont miss them.
"Shawnk" <Sh****@discussions.microsoft.com> wrote in message
news:9E**********************************@microsof t.com...

Thank you for letting me know of Anders 'Over my dead body' statement.

I have secretly harbored a suspicion that Java (and lately C#) is
inherently
'evil' because there is 'No Multiple Inheritance'. With Anders' statement
above I
now KNOW C# is inherently evil.

.....

And if C# IS inherently evil, AND today IS 6/6/6 (666), .... we MUST
consider the
possibility that Anders as actually .... evil incarnate masquerading as a
'being of
light' :-)

All of that great stuff (reflection, events, generics, LINQ) was actually
an EVIL FACADE to force us to live without MULTIPLE INHERITANCE.
(I see it all now !!!).

And since Anders IS such a wonderful and likeable guy (just a clever
masquerade) it all makes sense!

Strange as it may seem I had a dream (nightmare) last night in which
Anders played a flute leading the world's programmers to the 'Gates' of
hell.
As I entered the gate turned into a couple of giant legs.

I looked up an there was Bill 'Gates' as the devil (which makes Anders
just a
subservient demon) shouting 'No Multiple Inheritance for .NET' and then he
laughed wickedly.

The C# development team all had firery tridents and keep prodding the
incoming programmers
into teeny tiny cubicles. The C# Experts and MVPs walked on walls just
above
the cubicles
with whips and threatened code reviews.

And finally I saw Jon Skeet himself sitting on a high platform beating a
big
drum saying to each beat..

- No
- Multiple
- Inheritance
- No
- Multiple
- Inheritance
.....

Suddenly .. - I woke up in a cold sweat and couldn't get back to sleep
without the light being on.

......

Interesting how synchronisity and occult insights work on these new age
date
kind of things :-)

Thanks for the comment :-)

Shawnk

PS. Of course it could have been the anchovy pizza....

"Radek Cerny" wrote:
I guess all of us MI proponents stopped even dreaming when Anders uttered
those words "MI? Over my dead body!".

I miss MI dearly and would forego any and all other .NET improvments to
have
it.

Cheers

"Shawnk" <Sh****@discussions.microsoft.com> wrote in message
news:81**********************************@microsof t.com...
> Nicholas,
>
> Thank you for your response.
>
> The numbers in points [1] and [2] are completely contrived.
>
> We wanted to articulate the difference between (1) understanding and
> (2)
> use
> of II (Implementation Inheritance). We also wanted to establish a
> metric
> level for
> change (by evolution, user migration to other languages, user loyalty
> (as
> in
> C++)) that would account for the lack of MI (Mulitple Inheritance) in
> recent
> language offerings (java, C#, D++).
>
> The metrics of 'less than 1%' seemed to be a reasonable way to account
> for
> the apparent 'level of interest' (lack of interest) in MI/SFM among
> 'expert'
> and 'senior' level programmers in the non-C++ programming communities.
>
> As to 'why MI is not supported' - the lack of interest or the response
> to
> this post is an indication that verifies (informally) the 'less than
> 1%'
> water mark. And yes, ... it appears that the II, MI and SFM are not
> used/understood/desired in the non-C++ programming communities :-)
>
> We wanted to post this question in several language communities prior
> to
> any
> other actions (such as recommendations, etc). Also, making
> recommendations
> would be distracting to an audience/community that has no
> interest/understanding/desire of the utility of MI/II/SFM.
>
> Your good point about a recommended design implementation for MI in C++
> (in
> my mind) is really hinged/connected to Anders position of 'no MI in
> C#'.
> Since all the videos, interviews, etc. (That I have seen) indicate he
> has
> NO
> interest in MI/II/SFM it is reasonable to assume that C# will always be
> a
> less expressive (relative to functional orthogonality) and powerful
> language
> compared to C++.
>
> Note that C# is an excellent language and wonderfully expressive from a
> productivity standpoint (type safety, etc). Its current contribution
> via
> LINQ
> is excellent as its historic introspective (reflection) and binding
> (delegates,events) mechanisms. As a mechanism for automated pattern
> detection
> and refactoring it fails (IMHO) because of the importance of
> functionally
> orthogonal mechanisms (such as MI/II/SFM, etc).
>
> The lack of use of .NET in the Microsoft Vista implementation is
> something
> of interest (to the MI/II/SFM issues) that we will pursue (as opposed
> to
> C#
> recommendations) to get a feel for MI/II/SFM issues in various
> programming
> communities.
>
> Thanks again for your input.
>
> Shawnk
>
> PS. The lack of MI/II/SFM in .NET is a basic, serious and fundamental
> flaw
> (IMHO) of the 'operating system' (as in .NET) itself. This, of course,
> hinges
> on the validity of point [3] which is the basis for Ander's position on
> MI
> in
> C#.
>
>
> "Nicholas Paldino [.NET/C# MVP]" wrote:
>
>> I would be interested in knowing how you came to the numbers that
>> you
>> have in points 1 and 2.
>>
>> While I agree that implementation inheritance would be useful, if
>> the
>> numbers that you claim are anywhere near correct, you have already
>> answered
>> why MI is not supported in modern languages (meaning most .NET
>> languages,
>> Java).
>>
>> In all of this, I didn't see a recommendation on how such
>> functionality
>> might be included in C# (proposed language syntax, rules, etc, etc).
>> Why
>> not show something of that nature?
>>
>>
>> --
>> - Nicholas Paldino [.NET/C# MVP]
>> - mv*@spam.guard.caspershouse.com
>>
>> "Shawnk" <Sh****@discussions.microsoft.com> wrote in message
>> news:37**********************************@microsof t.com...
>> > Some Sr. colleges and I have had an on going discussion relative to
>> > when
>> > and
>> > if
>> > C# will ever support 'true' multiple inheritance.
>> >
>> > Relevant to this, I wanted to query the C# community (the 'target'
>> > programming
>> > community herein) to get some community input and verify (or not)
>> > the
>> > following
>> > two statements.
>> >
>> > [1] Few programmers (3 to7%) UNDERSTAND 'Strategic Functional
>> > Migration
>> > (SFM)' (see PS below).
>> >
>> > [2] Of those few, even less (another 3 to 7%) are GOOD at Strategic
>> > Functional Migration (or 0.9% to 0.49%).
>> >
>> > Do these percentages seem about right? (less than 1% of the target
>> > programming
>> > community are GOOD at SFM)
>> >
>> > Thanks ahead of time for any relevant QUALITY input.
>> >
>> > Shawnk
>> >
>> > PS.
>> >
>> > Strategic Functional Migration (SFM) is described in the post
>> > following
>> > this
>> > one.
>> >
>> > PPS. I submit to my fellow colleges that the answer (point spread)
>> > determines
>> >
>> > [A] Short term mitosis of the few to pioneer a new language
>> > incorporating
>> > C#
>> > productivity with C++ (SFM) powers
>> >
>> > [b] Long term community evolution and industry migration away from
>> > C#
>> > as a
>> > 'core competency' solution (subtle point)
>> >
>> > Both A/B, in turn, instantiate the 'early adopter' model in the
>> > compiler
>> > market.
>> >
>> > PPPS.
>> >
>> > I have a 'core competency' project I want to do that would be a lot
>> > easier
>> > if I
>> > could use SFM with C#.
>>
>>
>>

Jun 7 '06 #8

Radek Cerny <ra*********@nospam.c1s.com.au> wrote:

Wow. I love anchovy pizza - never had that as a result. Maybe its all true
and you are psychic.
Its sad how so many otherwise helpful and intelligent people are so anti-MI.
Maybe its what you grow up with and get used to - like having legs, arms and
eyes. If you've never had them, you dont miss them.

Have you considered how the reverse might be true as well - how if
you've always walked using a crutch, you might consider that to be
vital even if other people seem to be able to run perfectly well
without one?

I agree that it's largely a case of what you're used to, but I don't
think it's fair to be one-sided about that understanding.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jun 8 '06 #9

Shawnk

Radek,

All humor aside :-) I must admit that many of us in the community are
still learning after many years of coding. The issues of MI (Mulitple
Inheritance),
II (Implementation Inheritance) and VI (Virtual Inheritance) are still in a
state
of flux as is evident in the WikiPedia entries. See discussion on;

http://en.wikipedia.org/wiki/Virtual_inheritance

Hopefully discussion will continue in this and other forums (including
WikiPedia) to separate the implementation difficulties of MI and SFM
(Strategic Functional Migration) from the theory of code reuse.

I expect that current works in progress regarding automated refactoring
metrics and analysis (over the next few years) will provide a solid
foundation for a fundamental articulation of inheritance and functionality.

I feel that Anders (God Bless him :-) is very close to the problem and is
driven (primarily) in his thinking by the implementation issues (dev team
perspective) and not the customer SFM, code reuse issues (compiler user
perspective).

Thanks for your comments.

Shawnk

Jun 8 '06 #10

Shawnk

Jon,

I always look forward to your posts :-)

IMHO the SFM, MI, code reuse issue is a fundamental scientific fact based on
physically inherent metrics. There are under the cover issues (clearly) with
MI implementations but these are artifacts of past and current languages.

Hopefully future languages will 'build on the shoulders of Giants' (so to
speak) and provide MI with a clear articulation of implementation directives
(and default preferences) to solve the classic 'diamond problem'.

Your past comments regarding '... the idiom' of .NET and its inability to
implement MI is a key statement. The flaw (lack of MI) starts in the .NET CLR
and is complicated by different semantics for MI in different languages.

A key point is that MI is not a 'crutch' (with all due respect) but rather a
'fundamental truth' in programming Von Neumann machines (Vs neural nets, etc).

Clearly any implemetation code that is replicated for more than one class
and is FUNCTIONALLY IDENTICAL is 'replicated code'. Replicated code should be
factored out and used via MI. An important note. The term 'Functionally
Identical' herein refers to the lanaguage expression of 'what the customer
wanted' (the developer).

Solving the implementation problems is what the C# dev team (and other
language implementers) are paid for (with all due respect). No one, to date
and to my knowledge, has EVER successfully argued aganist the theoretical
merits of SFM, functional orthogonality, automated refactoring and
replication metrics.

All successful arguments (aganist MI that I have seen) are based on either
(1) ignorance or (2) implementation realities, difficuties and pragmatic (and
very real) engineering political issues (language standards, etc). For
arguments under (2) the top three reasons aganist MI are rarely enumerated
(diamond problem, etc).

Type polymorphism (also called 'virtural inheritance' - but this term is
still in flux - see WikiPedia) is NOT II (Implementation inheritance). MI is
THE BEST SOLUTION to automated refactoring and code reuse metrics that
because of its fundamental elegance which can be metrically proven (character
count in the functional expressions of any programming language - for
example).

As always I would love to hear of your thoughts relative to VI, II and MI
and the relationship between them. Note that these three key concepts (VI,
II, MI) are still not formally agreed upon in the WikiPedia reference).

To call MI a 'crutch' without articulating the VI, II difference and
provability via lanauge expression metrics is indicative of many responses I
have seen from very intelligent industry pudits (such as yourself). Still, I
follow your responses quite a bit and look forward to any articulation you
may offer relative to metrics and provability regarding SFM, VI, II, MI and
functionally orthogonal refactoring.

As always, thanks so much for helpful responses.

Shawnk

PS. You are saint for helping so many people on this forum :-)

PPS. The 'one sided' impetus IMHO of MI supporters is the search for
objective truth in programming science backed up by formal metrics and
terminology.

"Jon Skeet [C# MVP]" wrote:

Radek Cerny <ra*********@nospam.c1s.com.au> wrote:
Wow. I love anchovy pizza - never had that as a result. Maybe its all true
and you are psychic.
Its sad how so many otherwise helpful and intelligent people are so anti-MI.
Maybe its what you grow up with and get used to - like having legs, arms and
eyes. If you've never had them, you dont miss them.

Have you considered how the reverse might be true as well - how if
you've always walked using a crutch, you might consider that to be
vital even if other people seem to be able to run perfectly well
without one?

I agree that it's largely a case of what you're used to, but I don't
think it's fair to be one-sided about that understanding.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jun 8 '06 #11

Hey, if there was hope, any hope that given enough examples (real world,
concrete examples) or other evidence that we need MI in the .NET CLR, that
resources would be assigned to that issue, then I would be happy to provide
more than enough of these.

I see the world, analyse the problems, design solutions using MI concepts.
I used to be able to implement the same. Coding is easy; design is the hard
bit - once you've done the design, you should be able to breathe easy
knowing its a simple process to implement. What bothers me is I have to
think differently (unnaturally) now that I know I can not implement with MI.

At least there is pizza & beer to ease the pain.

And it could be worse - we could be using Java :)

"Shawnk" <Sh****@discussions.microsoft.com> wrote in message
news:6E**********************************@microsof t.com...

Radek,

All humor aside :-) I must admit that many of us in the community are
still learning after many years of coding. The issues of MI (Mulitple
Inheritance),
II (Implementation Inheritance) and VI (Virtual Inheritance) are still in
a
state
of flux as is evident in the WikiPedia entries. See discussion on;

http://en.wikipedia.org/wiki/Virtual_inheritance

Hopefully discussion will continue in this and other forums (including
WikiPedia) to separate the implementation difficulties of MI and SFM
(Strategic Functional Migration) from the theory of code reuse.

I expect that current works in progress regarding automated refactoring
metrics and analysis (over the next few years) will provide a solid
foundation for a fundamental articulation of inheritance and
functionality.

I feel that Anders (God Bless him :-) is very close to the problem and is
driven (primarily) in his thinking by the implementation issues (dev team
perspective) and not the customer SFM, code reuse issues (compiler user
perspective).

Thanks for your comments.

Shawnk

Jun 8 '06 #12

Shawnk

Radek,

I could not agree with you more (especially the pizza/beer statement :-)

I'm gratified to have coded in C# for a number of years to better
appreciate binding (event/delegate) and introspection (reflection) concepts.

But still, C# turned out to be as I expected. A glorifed 'Java' that will
never incorporate MI and provide II for SFM and automated refactoring research
(let alone elegant designs and class libraries).

The recent contribution of LINQ reminds me a car salesman saying...

An THIS years model has a hottub in the backseat :-) Just feel that relaxing
warm water .....

Unfortunately, I wanted a car with tires on it (as in the power to go places
and do things). Having a modern mainstream (not specialized) programming
language
WITHOUT MI is like having a car without tires. The hottub is great
experience but
you still can't 'go' anywhere with it (relative to SFM, II and elegant
design work).

So my love affair with C# is over an I'm prefering C++ for the more complex
and
difficult tasks (combined with vendor class libraries to make up for .NET API
functionality). With SOA ports and vendor data storage in C++ I can relegate
C# for UI and
simple business stuff.

Also, I've programmed Biztalk. An excellent soultion written in C# that is
specialized
and indicates the similarity of C# to Cobol for business/IT programmers.

Still a pizza, some beer and really fast car (with tires of course) can go a
long way :-)

Thanks for the comments.

Shawnk
"Radek Cerny" wrote:

Hey, if there was hope, any hope that given enough examples (real world,
concrete examples) or other evidence that we need MI in the .NET CLR, that
resources would be assigned to that issue, then I would be happy to provide
more than enough of these.

I see the world, analyse the problems, design solutions using MI concepts.
I used to be able to implement the same. Coding is easy; design is the hard
bit - once you've done the design, you should be able to breathe easy
knowing its a simple process to implement. What bothers me is I have to
think differently (unnaturally) now that I know I can not implement with MI.

At least there is pizza & beer to ease the pain.

And it could be worse - we could be using Java :)

"Shawnk" <Sh****@discussions.microsoft.com> wrote in message
news:6E**********************************@microsof t.com...
Radek,

All humor aside :-) I must admit that many of us in the community are
still learning after many years of coding. The issues of MI (Mulitple
Inheritance),
II (Implementation Inheritance) and VI (Virtual Inheritance) are still in
a
state
of flux as is evident in the WikiPedia entries. See discussion on;

http://en.wikipedia.org/wiki/Virtual_inheritance

Hopefully discussion will continue in this and other forums (including
WikiPedia) to separate the implementation difficulties of MI and SFM
(Strategic Functional Migration) from the theory of code reuse.

I expect that current works in progress regarding automated refactoring
metrics and analysis (over the next few years) will provide a solid
foundation for a fundamental articulation of inheritance and
functionality.

I feel that Anders (God Bless him :-) is very close to the problem and is
driven (primarily) in his thinking by the implementation issues (dev team
perspective) and not the customer SFM, code reuse issues (compiler user
perspective).

Thanks for your comments.

Shawnk

Jun 8 '06 #13

Shawnk <Sh****@discussions.microsoft.com> wrote:

<snip>

I don't have much time (twins upstairs...) so I'm just going to pick up
on a couple of points in your post:

A key point is that MI is not a 'crutch' (with all due respect) but rather a
'fundamental truth' in programming Von Neumann machines (Vs neural nets, etc).
I'm afraid I really don't see the relation between the two - it's like
claiming that object orientation is fundamentally linked to Turing
machines, IMO.
Clearly any implemetation code that is replicated for more than one class
and is FUNCTIONALLY IDENTICAL is 'replicated code'. Replicated code should be
factored out and used via MI. An important note. The term 'Functionally
Identical' herein refers to the lanaguage expression of 'what the customer
wanted' (the developer).
And I would normally favour composition/aggregation in such cases,
rather than repeated code.
To call MI a 'crutch' without articulating the VI, II difference and
provability via lanauge expression metrics is indicative of many responses I
have seen from very intelligent industry pudits (such as yourself).

I wasn't so much arguing that it *is* a crutch, as trying to point out
the reverse of your analogy. Basically, I found your analogy a bit
arrogant - it amounted to: "If you disagree with me, then clearly you
don't understand the problem as well as I do." I take issue with that
statement - partly because even if *I* don't have very much experience
with various MI implementations, I rather suspect that people such as
Anders *have* done their homework, have all the information, and just
have a different opinion to yours. There's nothing wrong with there
being disagreements, but if the attitude of one side of that
disagreement isn't "I disagree with you" as "You clearly don't know
what you're talking about" then there isn't much room for useful
dialog.

For what it's worth, my main beef with MI is that however you choose to
solve the "diamond of death", you've added complexity. C# started off
as a very simple language, and has grown complexity already with
generics, nullable types etc. Those are pieces of complexity which I
can cope with as I can see tasks which are made much, much simpler by
using those abilities, every day. It's very rare that I come across a
situation in C# where I say: "I wish I had multiple inheritance." For
me, complexity *has* to come with a big benefit. Whenever you make code
harder to read, the upside has to be big. Considering two or more base
classes *is* a more complex situation, naturally making the thought
processes harder, IMO.

My guess is that your design decisions are led by exposure to MI as
much as mine are led by *non*-exposure to MI - in other words, you
naturally wish for MI instead of using other solutions which aren't as
idiomatic in the languages you use which have MI, but are in themselves
no worse than those MI solutions.

One thing I will say: I've recently started learning (and writing
about) Groovy, and the "new" (as in not in C#/Java :) features in there
get me really excited in terms of what I can do with them in a way that
MI never has done. In other words, Groovy is evidence that I'm not
blind to the possibilities of features I've never had access to before.
There are plenty of features not in C# which I would appreciate long
before we get down to MI.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jun 9 '06 #14

Jon,

I'll now have to pick on a few of your points...
Firstly

I rather suspect that people such as
Anders *have* done their homework, have all the information, and just
have a different opinion to yours. No. You cant trust/assume that. Just as you cant trust a politician to
tell you the truth. Here in Australia there's current debate regarding the
start of nuclear power generation. The government has launched a inquiry to
study it. Not the "feasability", but how to do it, as if its a done deal.
One of the key members of this "impartial" group is of course the head of
ASNTO (Australian Nuclear Science and Technology Organisation). We have so
much sun and wind power (and vast open space to capture this) that this
whole issue is a total farce. The government has not done its homework. And
yes has a different opinion from me. And from almost everyone else I know.

The SI/MI debate is almost religious in nature - and yes, Anders has a
different opinion from me. Jon, is there a god?

Next, It's very rare that I come across a
situation in C# where I say: "I wish I had multiple inheritance."
This happens (well used to happen) daily. I think/model/design different
from you.
My guess is that your design decisions are led by exposure to MI as
much as mine are led by *non*-exposure to MI - in other words, you
naturally wish for MI instead of using other solutions which aren't as
idiomatic in the languages you use which have MI, but are in themselves
no worse than those MI solutions.
My architecture leads to a complete normalisation of one's code base.
Everyone normalises their database design, but repeats code without
flinching. Since adopting c# (from Gupta/Centura 4GL) its been a very happy
world, EXCEPT that I am forced to repeat code - copy & paste - which offends
me greatly. I held hope for a few years but have now given up. I clearly
consider a solution where one is forced to repeat code worse than a solution
where you dont, thus an MI solution is better.

Radek

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Shawnk <Sh****@discussions.microsoft.com> wrote:

<snip>

I don't have much time (twins upstairs...) so I'm just going to pick up
on a couple of points in your post:
A key point is that MI is not a 'crutch' (with all due respect) but
rather a
'fundamental truth' in programming Von Neumann machines (Vs neural nets,
etc).

I'm afraid I really don't see the relation between the two - it's like
claiming that object orientation is fundamentally linked to Turing
machines, IMO.
Clearly any implemetation code that is replicated for more than one class
and is FUNCTIONALLY IDENTICAL is 'replicated code'. Replicated code
should be
factored out and used via MI. An important note. The term 'Functionally
Identical' herein refers to the lanaguage expression of 'what the
customer
wanted' (the developer).

And I would normally favour composition/aggregation in such cases,
rather than repeated code.
To call MI a 'crutch' without articulating the VI, II difference and
provability via lanauge expression metrics is indicative of many
responses I
have seen from very intelligent industry pudits (such as yourself).

I wasn't so much arguing that it *is* a crutch, as trying to point out
the reverse of your analogy. Basically, I found your analogy a bit
arrogant - it amounted to: "If you disagree with me, then clearly you
don't understand the problem as well as I do." I take issue with that
statement - partly because even if *I* don't have very much experience
with various MI implementations, I rather suspect that people such as
Anders *have* done their homework, have all the information, and just
have a different opinion to yours. There's nothing wrong with there
being disagreements, but if the attitude of one side of that
disagreement isn't "I disagree with you" as "You clearly don't know
what you're talking about" then there isn't much room for useful
dialog.

For what it's worth, my main beef with MI is that however you choose to
solve the "diamond of death", you've added complexity. C# started off
as a very simple language, and has grown complexity already with
generics, nullable types etc. Those are pieces of complexity which I
can cope with as I can see tasks which are made much, much simpler by
using those abilities, every day. It's very rare that I come across a
situation in C# where I say: "I wish I had multiple inheritance." For
me, complexity *has* to come with a big benefit. Whenever you make code
harder to read, the upside has to be big. Considering two or more base
classes *is* a more complex situation, naturally making the thought
processes harder, IMO.

My guess is that your design decisions are led by exposure to MI as
much as mine are led by *non*-exposure to MI - in other words, you
naturally wish for MI instead of using other solutions which aren't as
idiomatic in the languages you use which have MI, but are in themselves
no worse than those MI solutions.

One thing I will say: I've recently started learning (and writing
about) Groovy, and the "new" (as in not in C#/Java :) features in there
get me really excited in terms of what I can do with them in a way that
MI never has done. In other words, Groovy is evidence that I'm not
blind to the possibilities of features I've never had access to before.
There are plenty of features not in C# which I would appreciate long
before we get down to MI.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jun 10 '06 #15

Radek Cerny <ra*********@nospam.c1s.com.au> wrote:

I'll now have to pick on a few of your points...
Firstly
I rather suspect that people such as
Anders *have* done their homework, have all the information, and just
have a different opinion to yours. No. You cant trust/assume that. Just as you cant trust a politician to
tell you the truth. Here in Australia there's current debate regarding the
start of nuclear power generation. The government has launched a inquiry to
study it. Not the "feasability", but how to do it, as if its a done deal.
One of the key members of this "impartial" group is of course the head of
ASNTO (Australian Nuclear Science and Technology Organisation). We have so
much sun and wind power (and vast open space to capture this) that this
whole issue is a total farce. The government has not done its homework. And
yes has a different opinion from me. And from almost everyone else I know.

Having spoken to Anders about various issues, he doesn't come across as
someone who gives an opinion on something without having put
significant thought into it.
The SI/MI debate is almost religious in nature - and yes, Anders has a
different opinion from me.
And that's fine, until anyone decides that they should say that anyone
with a different opinion just doesn't understand the issue.
Jon, is there a god?
Yes, in my view :)
Next,
It's very rare that I come across a
situation in C# where I say: "I wish I had multiple inheritance."
This happens (well used to happen) daily. I think/model/design different
from you.

Indeed - and from that, you seem to be assuming that I believe in copy
and paste as a good way of working. I don't - it's just that I don't
use MI as a way of avoiding cutting and pasting.

My guess is that your design decisions are led by exposure to MI as
much as mine are led by *non*-exposure to MI - in other words, you
naturally wish for MI instead of using other solutions which aren't as
idiomatic in the languages you use which have MI, but are in themselves
no worse than those MI solutions.

My architecture leads to a complete normalisation of one's code base.
Everyone normalises their database design, but repeats code without
flinching.

Now you're the one making assumptions. I don't repeat code without
flinching - far from it. Sometimes I cut and paste code, but always
with a view to refactoring in the *very* near future.
Since adopting c# (from Gupta/Centura 4GL) its been a very happy
world, EXCEPT that I am forced to repeat code - copy & paste - which offends
me greatly.
I find it very rare that I need to cut and paste code, despite not
using MI. Many problems have more than one solution.
I held hope for a few years but have now given up. I clearly consider
a solution where one is forced to repeat code worse than a solution
where you dont, thus an MI solution is better.

And the flaw in that logic is the assumption that MI is a requirement
for not repeating code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jun 10 '06 #16

Is there a simple example that can underline the realized benefits of using
multiple inheritance?

As someone (and I'm sure that I'm not alone) thats never been allowed the
luxury of designing within an MI language, I can't really appreciate the
need for it.

Most of the contrived examples I could come up with were pretty easy to solve
via multiple interface inheritance and single implementation inheritance.

No code was duplicated and the solution didn't really lose clarity. Actually
(and this might be due to my lack of exposure to MI), the purpose of the
final object seemed clearer.

FYI: I went C --> Java --> C#

--
Saad Rehmani / Prodika / Dallas / TX / USA

Continued Post : Strategic Functional Migration and Multiple
Inheritance

----definition----

Strategic Functional Migration : SFM

[1] Factoring out common functionality to base classes.

[2] Using common functionality via the Implementation Inheritance (II)
feature of Multiple Inheritance (MI).

----discussion----

In this post I would like to forgo any mention of 'under the cover'
issues
when
implementing multiple inheritance in compilers. Thus to focus on user
(not
vendor) issues (in 'strategic code library design') over long periods
of time.
[Subtle point] This arena of a comporate 'code base' is the 'core
competency'
code that forms the heart of any corporate IP driven (Intellectual
Property)
budget expenditures. Thus infering C# to be more suited to 'non-core
competency' code (software infrastructure, common stuff, UI, General
Business apps).
Core competency examples would be data analysis (Telemetry, data
mining, high
performance data flow, complex process and automation 'software
engines',
data probes, etc.) and data processing.
Thus, this post is not relevant to 'Time' or 'Cost' focused projects
but
towards
more complex designs (rich functional landscape for functional
migration)
and 'Quality' driven projects. So, for example, IT Bandage
programming (not
to be
pejorative) is not of interest here.
(Obvious : All projects have TCQ ('tque' - Time, Cost, Quality ) -
Strategic planning and technology investment is the venue and focus
here)

Note : 'True' Multiple Inheritance (MI) exhibits both

(1) Implementation Inheritance (II)
and
(2) Virtual Inheritance (VI)
See;

http://en.wikipedia.org/wiki/Inherit...mputer_science)
http://en.wikipedia.org/wiki/Virtual_inheritance
http://en.wikipedia.org/wiki/Multiple_inheritance

Interfaces provide the semantics for (1) but not (2).
Thus interfaces, by definition, do not support implementation
inheritance
(II).
See;

http://en.wikipedia.org/wiki/Interfa...mputer_science)

Note : Any discussions/responses on SFM and 'polymorphic
substituability'
(multi-role entiies - role substituion - interface aspect -
programming
perspective - orthogonal hierarchies) ARE related (and
relevant) but NOT requested. This allows the post to focus responses
on SFM
awareness/ignorance in the target programming community.
If you must respond on the merit of SFM (we all have passion that
makes
significant
impact on the community) - please relate your key points to quotes
from the
wikipedia references. This helps Wikipedia contributors (writers)
reuse your
arguments and
(eventually) reflect your ideas back into this target programming
community.
----summary--

In the post following this post - an example of 'strategic functional
mirgration' is given using non-GOF patterns;

- EOP (Event Observer Pattern) and
- SMP (State Machine pattern)
(no code in example - just a quick Sr. Architect hip shot)

Shawnk

Jun 11 '06 #17

"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...

Is there a simple example that can underline the realized benefits of
using multiple inheritance?

There are a number of examples in "Design Patterns".

///ark

Jun 11 '06 #18

I'm quite familiar with GoF :)

I believe quite a few books out there prove they can all be implemented without
multiple inheritance.

So, once again, what am i losing when i implement a <random GoF pattern here>?

Cheers :)

--
Saad Rehmani / Prodika / Dallas / TX / USA

"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...
Is there a simple example that can underline the realized benefits of
using multiple inheritance?

There are a number of examples in "Design Patterns".

///ark

Jun 11 '06 #19

"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...

I'm quite familiar with GoF :)
I believe quite a few books out there prove they can all be implemented
without multiple inheritance.

Everything can be implemented through ones and zeros. There is nothing --
pattern or application -- that requires multiple inheritance, single
inheritance, or even a programming language. People with experience in MI,
however, feel they are more productive with its judicious use.

Observer is one pattern that the GoF implement using inheritance, so
obviously if you also needed to inherit from something else, you'd want
multiple inheritance.

But there's nothing that can be done with inheritance (forget multiple
inheritance) that can't be done with composition and delegation. Or ones and
zeros.

Does that answer your question? Frankly, I think you've already answered it
to your own satisfaction.

///ark

Jun 11 '06 #20

Ian Semmel

As someone who used MI (a mistake) in an MFC project, I can assure you there are
no benefits.

eg if you have class C derived from A and B, but then you want to add a new
class A1 derived from A that adds extra functionality and a new class B1, then
class C is screwed up and it all gets very messy.

Saad Rehmani wrote:

Is there a simple example that can underline the realized benefits of
using multiple inheritance?
As someone (and I'm sure that I'm not alone) thats never been allowed
the luxury of designing within an MI language, I can't really appreciate
the need for it.
Most of the contrived examples I could come up with were pretty easy to
solve via multiple interface inheritance and single implementation
inheritance.
No code was duplicated and the solution didn't really lose clarity.
Actually (and this might be due to my lack of exposure to MI), the
purpose of the final object seemed clearer.

FYI: I went C --> Java --> C#

Jun 11 '06 #21

"Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
news:ez**************@TK2MSFTNGP02.phx.gbl...

As someone who used MI (a mistake) in an MFC project, I can assure you
there are no benefits.

eg if you have class C derived from A and B, but then you want to add a
new class A1 derived from A that adds extra functionality and a new class
B1, then class C is screwed up and it all gets very messy.

In that scenario, C would not be affected, so there must have been more to
it than that.

I must say that I've found MI most useful in mixin situations, where the
classes I'm deriving from are orthogonal. The "SeaPlane derives from both
Plane and Boat" idea is not a good use of MI.

Jun 11 '06 #22

Mark Wilden wrote:

"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...
I'm quite familiar with GoF :)
I believe quite a few books out there prove they can all be
implemented
without multiple inheritance.
Everything can be implemented through ones and zeros.
I think you're on the wrong list ... ;)
There is nothing
-- pattern or application -- that requires multiple inheritance,
single inheritance, or even a programming language. People with
experience in MI, however, feel they are more productive with its
judicious use.

Observer is one pattern that the GoF implement using inheritance, so
obviously if you also needed to inherit from something else, you'd
want multiple inheritance.
I looked up the observer pattern in GoF. The two implementations I'm referencing
are the one that uses MI in GoF (DigitalClock) and the SI version at http://www.dofactory.com/Patterns/PatternObserver.aspx

The MI version (i think i'm about to diss GoF, kill me now! ;]) seems to
lack division of responsibility. The DigitalClock doesn't really specialize
the behavior of the Widget its inheriting from, what its really doing is
extracting data from the subject prior to calling Draw(). In ASP.NET terms,
this seems like more of a PreRender() task than part of the Render(). In
more generic terms, it seems like a data binding operation is being performed
inside the specialized Draw() to overcome for the widget not allowing us
a way to plugin a different datasource.

If we were to take that away, we'd be left with a pluggable subject and pluggable
datasource, which brings me to the SI version.

Assuming that widget doesn't allow us to plugin a datasource, the SI version
would end up with extra code to adapt the Observer to set the state on various
types of widgets.

But there's nothing that can be done with inheritance (forget multiple
inheritance) that can't be done with composition and delegation. Or
ones and zeros.

Does that answer your question? Frankly, I think you've already
answered it to your own satisfaction.
If this how multiple inheritance is sold to non-believers, I can see why
it hasn't gained any traction :)

///ark

Feel free to remind me how lost I am :)

--
Saad Rehmani / Prodika / Dallas / TX / USA

Jun 12 '06 #23

Ian Semmel wrote:

As someone who used MI (a mistake) in an MFC project, I can assure you
there are no benefits.

eg if you have class C derived from A and B, but then you want to add
a new class A1 derived from A that adds extra functionality and a new
class B1, then class C is screwed up and it all gets very messy.
Are you talking about the Diamond problem (http://en.wikipedia.org/wiki/Diamond_problem)
....?

Saad Rehmani wrote:
Is there a simple example that can underline the realized benefits of
using multiple inheritance?
As someone (and I'm sure that I'm not alone) thats never been allowed
the luxury of designing within an MI language, I can't really
appreciate
the need for it.
Most of the contrived examples I could come up with were pretty easy
to
solve via multiple interface inheritance and single implementation
inheritance.
No code was duplicated and the solution didn't really lose clarity.
Actually (and this might be due to my lack of exposure to MI), the
purpose of the final object seemed clearer.
FYI: I went C --> Java --> C#

Jun 12 '06 #24

"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...

If we were to take that away, we'd be left with a pluggable subject and
pluggable datasource, which brings me to the SI version.
The single inheritance version (as do all single-inheritance replacements of
multiple inheritance implementations I've seen) replaces inheritance with
delegation. I don't like that approach because it means duplication, and I
hate duplication. If you change the delegated-to object's interface, you
have to do the same to the delegator's interface (usually). It's not a big
deal, and lots of VB, C# and Java programmers are perfectly comfortable with
it, but I prefer to let MI do the work for me.

MI has given lots of programmers problems (there's another poster on this
thread who doesn't even seem to be quite sure what his problems were), and
simplicity is good, too.

MI has a serious problem in the realm of Java and C# in that everything
descends from a single base class. Does a multiply-derived object have two
Object bases or one? C++ solved that, but still some folks had trouble with
it.

My point, however, is that four of the most influential software thinkers
ever were quite happy with MI. Five, if you count me. :) That should mean
something.
If this how multiple inheritance is sold to non-believers, I can see why
it hasn't gained any traction :)

I never try to sell things to non-believers.

///ark

Jun 12 '06 #25

"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...

Ian Semmel wrote:
As someone who used MI (a mistake) in an MFC project, I can assure you
there are no benefits.

eg if you have class C derived from A and B, but then you want to add
a new class A1 derived from A that adds extra functionality and a new
class B1, then class C is screwed up and it all gets very messy.

Are you talking about the Diamond problem
(http://en.wikipedia.org/wiki/Diamond_problem)

He might be, but his description doesn't indicate as much. The "deadly
diamond of death" would still be a problem with C (unless he used virtual
inheritance) long before introducing A1 and B1. The hiearchy described is

A --|
|------ C
B --|

Changing that to

A --|------ A1
|------ C
B --| ------ B1

clearly doesn't affect C.

(BTW, I think that article misses the main problem with the diamond, which I
described in another message.)

///ark

Jun 12 '06 #26

Ian Semmel

Mark Wilden wrote:

"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...
Ian Semmel wrote:

As someone who used MI (a mistake) in an MFC project, I can assure you
there are no benefits.

eg if you have class C derived from A and B, but then you want to add
a new class A1 derived from A that adds extra functionality and a new
class B1, then class C is screwed up and it all gets very messy.

Are you talking about the Diamond problem
(http://en.wikipedia.org/wiki/Diamond_problem)

He might be, but his description doesn't indicate as much. The "deadly
diamond of death" would still be a problem with C (unless he used virtual
inheritance) long before introducing A1 and B1. The hiearchy described is

A --|
|------ C
B --|

Changing that to

A --|------ A1
|------ C
B --| ------ B1

clearly doesn't affect C.

(BTW, I think that article misses the main problem with the diamond, which I
described in another message.)

///ark

Unless I need a C1 which inherits from A1, B1 and C

Jun 12 '06 #27

Saad Rehmani wrote:

<snip>

Assuming that widget doesn't allow us to plugin a datasource, the SI
version would end up with extra code to adapt the Observer to set the
state on various types of widgets.

Assuming its not sealed, one could just subclass it to introduce delegation
and get back to the cleaner version.

I wake up slowly on Mondays :)

<snip>

--
Saad Rehmani / Prodika / Dallas / TX / USA

Jun 12 '06 #28

"Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
news:OR**************@TK2MSFTNGP03.phx.gbl...

He might be, but his description doesn't indicate as much. The "deadly
diamond of death" would still be a problem with C (unless he used virtual
inheritance) long before introducing A1 and B1. The hiearchy described is

A --|
|------ C
B --|

Changing that to

A --|------ A1
|------ C
B --| ------ B1

clearly doesn't affect C.

Unless I need a C1 which inherits from A1, B1 and C

Sure, but that wasn't mentioned as the problem under discussion.

Your scenario could still be handled with virtual inheritance, that would
leave C1 with just one A, B, A1, B1, and C base class object. The problem,
of course, is if the A1 derivation isn't under your control, and it wasn't
made virtual.

Jun 12 '06 #29

Shawnk

Jon,

Sorry for the slow response. Took off a few days (long weekend) to enjoy the
summer.. Congradulations on the twins :-)

In answer to some of your excellent points..

I'm afraid I really don't see the relation between the two - it's like
claiming that object orientation is fundamentally linked to Turing
machines, IMO.
In a non-single CPU design an argument (against MI, etc) can be
made by saying each class would have its own processor. The
intent (of the statement) was to focus the context (of MI use)
and re-enforce the 'scientific metric' point about physical phenomena
in the context of a 'Turing machine'.
it's like claiming that object orientation is fundamentally linked to Turing
machines, IMO.
Exactly. I accept that you may not agree. No problem.
I found your analogy a bit arrogant -
Cringe. Those who don't know me tend to see that while those that do
see me as having a casual 'matter of fact' attitude coupled with a
strong passion for truth, justice and the American way :-)
(... I just could not resist. PS. American way is to question
your superiors .. in this case Anders' approach to language expression
in C#).
I rather suspect that people such as Anders *have* done their homework...
room for useful dialog.
God forbid! I've learned a lot from this forum and our dialog should
(hopefully)
be refined and focused to core points on fundamental expression constructs
in C# and ultimately all computer languages. Our mutual desire for
truth and understanding is intrinsic to 'men of science' personalities
such as engineers, programmers, scientists etc.
For what it's worth, my main beef with MI is that however you choose to
solve the "diamond of death", you've added complexity.
I qualified the 'diamond of death' issue as an 'under the cover' issue to
decouple (for these posts and thread) what the compiler generates from what
the
programmer writes.

Thus we come to a THE point of this thread which is 'complexity' of the
language
as it is written.

Complexity being measured (a la information theory) as a simple character
count
of the MI/SI expression alternatives. Again -- the focus on language
expression
is vital (to this discussion) because this thread would be to big if we
include
under the cover issues such as diamond of death. My intent is to get
information from this thread/series of posts to estimate/calculate these
comparative metrics of language expression - not metrics comparisons of
compiler generation.
Whenever you make code harder to read, the upside has to be big. Considering
two or more base classes *is* a more complex situation, naturally making the
thought processes harder, IMO. ....And I would normally favour composition/aggregation in such cases,
rather than repeated code.

This is exactly what I was searching for in this thread. A clear
concise and focused articulation of the conceptual comparison of
MI and proposed alternatives. (From someone who I respect :-)

[1] Composition
[2] Aggregation

In [2], functional agregation can be accomplished via MI or by embedding a
class
within a class. Both (MI, embedding) are agregation mechanisms. To clarify
your meaning - Did you mean - for example ...-

In creating a functional unit (class) Fu (in C#) that needs functionality from
classes Fx, Fy, Fz (three classes) you would inherit from either Fx, Fy or Fz
and embed the other two classes?

Note that Fx, Fy, and Fz are inherent (complete,
closed, concise) and functionally orthogonal in nature. Thus (for this
example)
you do not want to re-compose Fx, Fy, Fz (sin, cosine and other trig functions
would be an example, but it applies to all computing functionality).

Please let me know if I understand your design approach (regarding [2]
aggregation)
correctly.

Also, given the 'embed' approach how would [1] composition be used the add,
take
away or bring out the target functionality of Fx, Fy, Fz. (Note the example
criterion of non-restructuring of the Fx, Fy and Fz functionality.)

I want to thank you, again, for your response. Getting a clearly articulated
response from some one of your caliber will help (hopefully) many of us MI
proponents to better understand your points regarding the MI alternatives of
[1]
and [2].

My hope that much of the work done by those responding to these posts (on MI
in
C#) will find its way to WikiPedia in the form of a definitive set of
scientific
metrics, terminology and concepts regarding functional aggregation
mechanisms in
Von Neumann machines. Hopefully this will also help the C#/.NET community
as well in a better understanding of expression alternatives for functional
aggregation.

Shawnk

PS. I'll have to look into the Groovy langage you mentioned.

Jun 13 '06 #30

Shawnk

Radek,

Your comment...

My architecture leads to a complete normalisation of one's code base.
Everyone normalises their database design, but repeats code without
flinching.

... makes an excellent point. The use of 'normalisation' is a key term I was
hoping to find to better express the aggregation and composition effects
of MI.

In the future I'll try to develop the term 'functional normalisation' to refer
to aggregating a compositional result (as in Fx, Fy, Fz being three
functionally orthogonal classes in OOP) into one functional unit (Fu created
by MI from Fx, Fy, and Fz).

Thanks for articulating the normalized state of function (in the final
design) many of us MI proponents unconciously infer.

Shawnk

Jun 13 '06 #31

Shawnk

Jon,

As always, your articulate and thoughtful points are always appreciated.

And the flaw in that logic is the assumption that MI is a requirement for not
repeating code.
That is exactly my point (an hopefully the point of most MI proponents).

Some question as to (1) requirement Vs. (2) best solution could be made
and we should be clarify this (1) vs (2) issue before continuing.

Radek's excellent articulation of 'functional normalization' is perhaps the
most
succinct term to embody the architectural intention of MI. Which is, a
minimal
expression to aggregate class functionality while still keeping the
pre-existing
(to the aggregation) intrinsic functional composition (that classes provide)
intact.

Herein 'functional composition' is intended to mean the ability to enforce
'orthogonality' via placing some function in a given class. Each class
expressing a 'dimension' of functionality (as it were).

The resulting structural (not behavioral) separation allows the functionality
(classes) to be combined, via MI, in what I (and hopefully other MI
proponents)
know to be metrically provable minimal expression.

So, your point of...
And the flaw in that logic is the assumption that MI is a requirement for not
repeating code.

... is in fact our mutual question. IS MI an intrinsic (1) requirement because
it provides the metrically proven (2) best solution?

If (2) then (1) would be the synopsis. If (2) MI is the best solution
for both (A) functional normalization (excellent term from Radek) and
(B) functional agregation then (1) MI is a requirement for not
repeating code.

Note that the functional normalization comes as an inherent effect
of classes (OOP). Given that any example design is functionally
orthogonal and normalized in the class architecture we then
need a mechanism to aggregate them.

MI provides the only mechanism to functionally aggregate classes
AND pass that functionality through to the surface API of the aggregate
functional unit.

Shawnk

PS. I note in passing I have issues with the term 'composition' but do not
want
to digress from a focus on 'functional normalization'. Basically in runtime
'behaviour' composition refers to the effect (in time) of several functions
'run' to product a particular effect (result). MI is a structural aggregation
mechanism that is semantically orthogonal to the runtime effect of
composition.
The structural vs behavioral aspect is clearly demonstrated by limiting
discussion
to the structural aggregation effect of a MI vs a SI/Interface approach to
expression mechanisms.

Jun 13 '06 #32

Shawnk

Saad,

Sorry for my slow response. I had a long weekend :-)

Is there a simple example that can underline the realized benefits of using
multiple inheritance?
There are some examples but I have tried to focus this thread by ignoring
the following -

[1] Syntax
[2] Composition (calling a sequence of functions to produce a 'aggregate
effect' of functionality).
[3] Under the cover 'implementation issues' dealing with what the compiler
generates (diamond problem, etc).

The intent of the focus in this thread is to discuss SFM (Strategic
Functional Migration) as a means
to find some better terminology related to the MI/SI-Interface debate.

A key contribution (in this thread) from Redek Cerny in his concept of
'functional normalization' which
is a core intent of MI.

Any presentation of syntax should be preceded and followed by a articulation
of the architectural
features of interest (the key intellectual points of the design).

Jon Skeets excellent comments
regarding the use of [1] Composition and [2] Agregation are an excellent
example of the ineffectiveness
of our current terminology (in OOP) to distinguish the phenomena of
'functional normalization' from
a structural agregation perspective.

The communitive, associative and distributive aspects of mathematical
effects is the basis for
the communitive aspect of [1] Composition. The use of calling several
methods/functions to produce
the same computing result as a single method/function is an approach to
replicate/replace/mimic MI.

Rather than presenting a syntactic example of these communitive effects of
composition
I would prefer (being very busy, etc) to provide a link
to WikiPedia that contains a definitive syntactic example -

http://en.wikipedia.org/wiki/Composition
http://en.wikipedia.org/wiki/Composi...ter_science%29

In a similar manner my presentation of a 'hip shot' example
regarding -

Example of 'Strategic Functional Migration' : SFM

did not present syntax to focus on the terminology and concepts
at a more abstract (and fundamental) level.

Please excuse me and bear with us in this thread as my key concern
(besides a very informal feel for SFM understanding) is to articulate
the design features, relative to MI/SI-Interaface options, of various
agregation mechanisms in C# (and ultimately all computer languages).

Having read your discussion with Mark WIlden he did make a key point
that is very relevant to SFM/MI/SI-Interface and this thread -
My point, however, is that four of the most influential software thinkers
ever were quite happy with MI. Five, if you count me. :) That should mean
something.

I would have been more specific with the point to say ...

The ability of MI (Multiple Inheritance) to provide 'structural agregation'
in a 'functionally normalized' code base is a requirement for non-repeated
code fragments.

Another way of saying the same point ---

[4] The C# language and .NET can not support a 'functionally normalized'
code base.

This is a serious and fundamental flaw with .NET but not a fatal one (long
term).

If [4] is objectively true and can be metrically proven (within the context
of [1],[2], [3] above)
then .NET becomes another 'sandbox' similar to 'sandbox' concept introduced
in the Java/Web client
architectures.

To articulate the issue of SFM and a functionally normalized code base is
the core issue of this thread.

Radek Cerny's contribution of the idea of 'functional normalization' is an
concept that could be put
on WikiPedia (in time) and thus contain the syntactic examples you (and many
of us) desire.

Thank you for your input and I hope this articulation of 'MI/Structural
agregation/functional normalization'
has been helpful to you to better understand the key concern of MI
proponents with C# (and ultimately .NET).

Please feel free to comment on any concept herein that you feel is 'off the
mark' of the MI/SI-Interface debate.

Shawnk

Jun 13 '06 #33

Shawnk

Mark,

Just a note in passing.

Redek's excellent comment on [0] 'functional normalization' is a concise
term to
articulate the 'realized benefit' of MI relative providing a structural
aggregation mechanism while still retaining the functional normalization of
the
orignal code base.

Ian Semmal's problems (valid or not) are indicative of the use of the
'strategic' connotation in the term 'Strategic Functional Migration'.

If we are given a non-functionally-normalized code base there is a cost
associated with refactoring/restructuring it using MI.

If we ignore the obvious port issue of C# to C++ ...

and focus on Ian Semmals example ...

The use of [1] Stratification in the [2] Inheritance Hierarchy coupled with
[3] MI
would solve all the problems (messy - meaning, I guess, non-normalized)
presented
to Ian (with all due respect Ian :-).

The [4] inability to normalize the code coupled with [5] an inability to
aggregate
the code are two separate problems which are not articulated (enumerated) in
Ian's discussion.

His example is quite helpful however in showing the utility of stratification
in providing 'inheritance threads' that would result in the exact
functionality
desired (assuming the functionality is well understood and can be normalized).

Your excellent comments the use of [1] Stratification to create [5] the target
functionality while maintaining [6] a functionally normalized code structure
enumerates the design approach quite well.

I note that concepts [0] and [1] help to distinguish concepts [4] and [5].

I propose that it may be possible to articulate a [8] formalized step wise
design
approach to [0] functional normalization via [1] Stratification and [3] MI.

The intent is to express the [0] 'functional normalization' as [9]
'functionally
orthogonal threads' of inheritance based on a [3] MI expression mechanism.

Just a passing thought :-)

Shawnk

PS. Thanks so much for your focused comment on the functional effects
of inheritance in your response to Ian Semmal's design problem.

Jun 13 '06 #34

Shawnk wrote:

Saad,

Sorry for my slow response. I had a long weekend :-)
Congratulations on the weekend. I didn't really have one, hehe :)

I've tried to respond to some of your questions. Please bear with me as I
am treating this as a learning experience.

Is there a simple example that can underline the realized benefits of
using multiple inheritance?
There are some examples but I have tried to focus this thread by
ignoring the following -

[1] Syntax
[2] Composition (calling a sequence of functions to produce a
'aggregate
effect' of functionality).

In general, composition allows more separation of concerns. Without componentizing,
we'd all be duplicating code. Over the last five or so years, I've become
a fan of lightweight component based models. The granularity of the calls
(SOA is an example) is really a design choice. Different strokes for different
folks ... err, contexts :)
[3] Under the cover 'implementation issues' dealing with what the
compiler
generates (diamond problem, etc).
Only concentrating on the strengths of an MI implementation would lead people
to make ill informed decisions. I did some reading up on how C++ deals with
the diamond problem. If C# were to actually implement MI, would that approach
work for you? I haven't really worked with MI so I don't really know if that
solution has any issues or not.
The intent of the focus in this thread is to discuss SFM (Strategic
Functional Migration) as a means
to find some better terminology related to the MI/SI-Interface debate.
A key contribution (in this thread) from Redek Cerny in his concept of
'functional normalization' which
is a core intent of MI.
Any presentation of syntax should be preceded and followed by a
articulation
of the architectural
features of interest (the key intellectual points of the design).
Jon Skeets excellent comments
regarding the use of [1] Composition and [2] Agregation are an
excellent
example of the ineffectiveness
of our current terminology (in OOP) to distinguish the phenomena of
'functional normalization' from
a structural agregation perspective.
The communitive, associative and distributive aspects of mathematical
effects is the basis for
the communitive aspect of [1] Composition. The use of calling several
methods/functions to produce
the same computing result as a single method/function is an approach
to
replicate/replace/mimic MI.
Rather than presenting a syntactic example of these communitive
effects of
composition
I would prefer (being very busy, etc) to provide a link
to WikiPedia that contains a definitive syntactic example -
http://en.wikipedia.org/wiki/Composition
http://en.wikipedia.org/wiki/Composi...ter_science%29
In a similar manner my presentation of a 'hip shot' example regarding
-

Example of 'Strategic Functional Migration' : SFM

did not present syntax to focus on the terminology and concepts at a
more abstract (and fundamental) level.

Please excuse me and bear with us in this thread as my key concern
(besides a very informal feel for SFM understanding) is to articulate
the design features, relative to MI/SI-Interaface options, of various
agregation mechanisms in C# (and ultimately all computer languages).

Having read your discussion with Mark WIlden he did make a key point
that is very relevant to SFM/MI/SI-Interface and this thread -
My point, however, is that four of the most influential software
thinkers ever were quite happy with MI. Five, if you count me. :)
That should mean something.
I would have been more specific with the point to say ...

The ability of MI (Multiple Inheritance) to provide 'structural
agregation' in a 'functionally normalized' code base is a requirement
for non-repeated code fragments.

Based on earlier posts in this thread (and I believe Mark agreed, he just
found the MI version more elegant in the end), it seems that most of the
code can be normalized if a delegation of concerns approach is used.

If I'm using the wrong word, please look at the code posted earlier.The only
part that couldn't be normalized was any adaption and that would only have
to happen once.

Another way of saying the same point ---

[4] The C# language and .NET can not support a 'functionally
normalized' code base.

This is a serious and fundamental flaw with .NET but not a fatal one
(long term).

If [4] is objectively true and can be metrically proven (within the
context
of [1],[2], [3] above)
then .NET becomes another 'sandbox' similar to 'sandbox' concept
introduced
in the Java/Web client
architectures.
To articulate the issue of SFM and a functionally normalized code base
is the core issue of this thread.

Radek Cerny's contribution of the idea of 'functional normalization'
is an
concept that could be put
on WikiPedia (in time) and thus contain the syntactic examples you
(and many
of us) desire.
Thank you for your input and I hope this articulation of
'MI/Structural
agregation/functional normalization'
has been helpful to you to better understand the key concern of MI
proponents with C# (and ultimately .NET).
Please feel free to comment on any concept herein that you feel is
'off the mark' of the MI/SI-Interface debate.

Shawnk

Jun 13 '06 #35

Shawnk <Sh****@discussions.microsoft.com> wrote:

<snip>

[3] Under the cover 'implementation issues' dealing with what the compiler
generates (diamond problem, etc).

<snip>

Just one thing: how you deal with the diamond of death is *not* an
implementation issue - it's a semantics issue. You need to define what
the semantics should be. I don't care how the compiler then implements
the spec, but I would care very much what the spec is.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jun 13 '06 #36

Shawnk <Sh****@discussions.microsoft.com> wrote:

And the flaw in that logic is the assumption that MI is a requirement for not
repeating code.
That is exactly my point (an hopefully the point of most MI proponents).

It's being treated as a given, however - which I don't grant, as I
don't repeat code despite not using MI.
Some question as to (1) requirement Vs. (2) best solution could be made
and we should be clarify this (1) vs (2) issue before continuing.
Even if MI were the best solution, it is not required while it is not
the *only* solution.
Radek's excellent articulation of 'functional normalization' is
perhaps the most succinct term to embody the architectural intention
of MI. Which is, a minimal expression to aggregate class
functionality while still keeping the pre-existing (to the
aggregation) intrinsic functional composition (that classes provide)
intact.
Except that you get not just the aggregate but potentially the
interference. I'm already not a fan of overuse of inheritance - see

http://msmvps.com/jon.skeet/archive/...itancetax.aspx

for more on this. I *generally* prefer composition to inheritance, even
without considering MI. MI just makes the same problem more complex,
IMO.
So, your point of...
And the flaw in that logic is the assumption that MI is a requirement for not
repeating code.
.. is in fact our mutual question. IS MI an intrinsic (1) requirement because
it provides the metrically proven (2) best solution?

If (2) then (1) would be the synopsis. If (2) MI is the best solution
for both (A) functional normalization (excellent term from Radek) and
(B) functional agregation then (1) MI is a requirement for not
repeating code.

No, that doesn't prove that it's a requirement, even if it's the best
solution. Something being the best solution doesn't mean that it's the
*only* solution. If another solution meets the requirement of not
repeating code, then MI itself is *not* a requirement for not repeating
code.
Note that the functional normalization comes as an inherent effect
of classes (OOP). Given that any example design is functionally
orthogonal and normalized in the class architecture we then
need a mechanism to aggregate them.

MI provides the only mechanism to functionally aggregate classes
AND pass that functionality through to the surface API of the aggregate
functional unit.

I prefer implementing multiple interfaces, and delegating the
implementation of each interface member to a separate implementation,
perhaps changing some of the implementations. Are there issues with
that approach? Yes, it's not always perfect. Does it avoid some of the
problems with inheritance? Absolutely. Could it be better supported in
languages? Yup. Does it provide a way of avoiding repeating code but
allowing an API which supports multiple interfaces? Absolutely.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jun 13 '06 #37

Shawnk <Sh****@discussions.microsoft.com> wrote:

In answer to some of your excellent points..
I'll only answer a few of your answers, again due to time I'm afraid.

I'm afraid I really don't see the relation between the two - it's like
claiming that object orientation is fundamentally linked to Turing
machines, IMO.

In a non-single CPU design an argument (against MI, etc) can be
made by saying each class would have its own processor. The
intent (of the statement) was to focus the context (of MI use)
and re-enforce the 'scientific metric' point about physical phenomena
in the context of a 'Turing machine'.

That seems like a very odd analogy, I'm afraid - I can't see how it
provides any benefit.

I found your analogy a bit arrogant -

Cringe. Those who don't know me tend to see that while those that do
see me as having a casual 'matter of fact' attitude coupled with a
strong passion for truth, justice and the American way :-)
(... I just could not resist. PS. American way is to question
your superiors .. in this case Anders' approach to language expression
in C#).

A matter of fact attitude is fine when we're talking about matters of
fact. I'm often viewed as arrogant on those issues as well - issues
where one can point to a spec and *prove* correctness. This is a matter
of *opinion* however, which is very different.

For what it's worth, my main beef with MI is that however you choose to
solve the "diamond of death", you've added complexity.

I qualified the 'diamond of death' issue as an 'under the cover' issue to
decouple (for these posts and thread) what the compiler generates from what
the programmer writes.

As I've said elsewhere, it's *not* an implementation issue. The effect
would have to be covered by the language specification.
Complexity being measured (a la information theory) as a simple character
count of the MI/SI expression alternatives.

I have to say, I think that's a very silly way of measuring complexity.
Would C# be a "simpler" language by making all the keywords single
letters? I don't believe so. It *certainly* wouldn't be a more readable
language.

The complexity I'm talking about is how hard it is to think about the
object model, and I believe that MI makes the model more potentially
complicated.

Whenever you make code harder to read, the upside has to be big. Considering
two or more base classes *is* a more complex situation, naturally making the
thought processes harder, IMO.

...
And I would normally favour composition/aggregation in such cases,
rather than repeated code.

This is exactly what I was searching for in this thread. A clear
concise and focused articulation of the conceptual comparison of
MI and proposed alternatives. (From someone who I respect :-)

[1] Composition
[2] Aggregation

In [2], functional agregation can be accomplished via MI or by embedding a
class
within a class. Both (MI, embedding) are agregation mechanisms. To clarify
your meaning - Did you mean - for example ...-

In creating a functional unit (class) Fu (in C#) that needs functionality from
classes Fx, Fy, Fz (three classes) you would inherit from either Fx, Fy or Fz
and embed the other two classes?

No. I would implement Ix, Iy and Iz by delegating each of the
implementations to an instance of each of Fx, Fy and Fz. Those
instances may be created by the class or specified externally (giving
flexibility). When writing Java in Eclipse, this is even supported very
simply by the IDE itself. It would be nice if there was a way of
expressing it in the language itself, but that wouldn't be equivalent
to MI.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jun 13 '06 #38

Shawnk

Saad,

Based on earlier posts in this thread (and I believe Mark agreed, he just
found the MI version more elegant in the end), it seems that most of the
code can be normalized if a delegation of concerns approach is used.

The phrase 'more elegant' I interpret to mean -

[1] Least character count in the aggregation expression.
[2] Maximum usable function within the body of the target class (created via
MI).
[3] Maximum usable function exposed to client users of the target class.

Jon Skeet's excellent point (about using the composition/aggregation mechanism
of Interface Inheritance) do not address the lack of [3] client exposure to
functionality provided by [4] embedding classes within the target class.

Hopefully Jon will provide us with a metric/construct (any metric/construct)
that can quantify/qualify the 'elegant' semantic inferred by Mark and
brilliantly
articulated by Redek qualification of 'functional normalization'.

In Jon's proposed design approach the increased character count needed to
'bring
out' the embedded class functionality to the surface API of a C# based,
embedded
aggregation approach is indicative of an 'in elegant' expression (IMHO).

That's (in elegant) an understatement actually - C# structural aggregation
mechanism's are laughable (presenting Multiple Interface Inheritance (MII)
as a
structural agregation mechanism) - except for the very real under the cover
issues that must be addressed in a multi-language sandbox like .NET.

Anders is justifiably concerned with these very important under the cover
issues.

Also, we are fortunate the Jon has taken the time to give us some excellent
points
to discuss (composition/aggregation) regarding the MI/SI-Interface issues.

I do want to note that, now that I think about it, there is an uncanny
similarity
between [5] replicated data in a non-normalized data base and [6] replicated
code in a
non-normalized code base (functionally normalized that is). The concept of
[7] normalization
is a very fundamental concept that could be formally related to metrics that
can prove the quality of normalized vs non-normalized code text (the language
expression - not the compiler generated implementation).

If this potential is realized a metric comparison between
expression/implementation features of Unix Vs .NET could be made.

Hopefully the articulation of 'functional normalization' and the fact that
..NET
may (jury still out on this) not support a 'functionally normalized' code base
will be helpful to better understanding SFM (Strategic Functional Migration)
in
the context of a .NET vs a non-.NET implementation (for large scale code bases
with thousands/millions lines of code).

Thank you for pointing out the 'elegant' focus of Mark's MI comment in an
'above
cover' context that focuses purely on the expressive capabilities and features
of a language (as opposed to a quality/lack-of-quality of a particular
implementation generated by a particular compiler).

Shawnk

Jun 13 '06 #39

Shawnk

Jon,

...it's a semantics issue...

I think there are both semantic and implementation aspects to MI.

That would be a fourth issue to ignore, that is the semantic meaning of MI
in the context
of several potential inclusion candidates.....

Just kidding (could not resist).

I do think selection of multiple candidates in a MI context is a solvable
problem (in theory) that does not present
a signifiant problem to MI.

The semantics of candidate selection (in practice) has a significant political
engineering aspect (language standard) however.

Since we are not hindered by these politics we should be able to solve the
semantic issue. I will review the semantic solutions to the diamond problem
and try to articulate the solution in a separate post dealing with the
semantic meaning of MI in the context of multiple candidates (for target
inclusion).

As a pre-cursor to that post it would behove us to identify the problem
(within
this thread) for introduction of a solution (in another thread).

Do you have any take on the various approaches to the semantics of candidate
selection? (in the context of MI). Or do you think that only one simple
problem/context exists?

Better yet do you have an enumerated set of categories that clearly
distinguishes
the different contexts of meaning that give rise to multiple candidates in
the first
place? (problem definition)

The context categories would be inclusive (I think) of both under cover
selection
and above cover semantics (from my point of view). But once noted, the above
cover semantics should be
fairly easy to enumerate and solve.

The under cover implementation aspects would be a little more involved and
best looked
at after a clearly articulated problem/solution discussion.

Thanks as always for your input and thoughtful comments.

Shawnk

PS. Redek Cerny's contribution regarding functional normalization could be a
significant
architectural impetus to guide the breakdown of the semantic context into a
good
set of categories (for problem articulation).

PPS. Perhaps Redek has a comment regarding the semantic context of multiple
candidate selection?

PPPS. 'Multiple candidate' infers one or more potential classes to select
from (what I call above the cover). 'Which state space' to select is the
phrase I use to enumerate the problem of how state space is distributed (or
not) in the final functional unit. 'State space conflict' is another term I
use for what I consider to be an implementation choice. Your inference that
multiple state space selection/distribution/choices are essentially semantic
in nature is noted (and deeply appreciated) as a valid point and argument.

Jun 13 '06 #40

Ian Semmel

Mark Wilden wrote:

"Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
news:OR**************@TK2MSFTNGP03.phx.gbl...
He might be, but his description doesn't indicate as much. The "deadly
diamond of death" would still be a problem with C (unless he used virtual
inheritance) long before introducing A1 and B1. The hiearchy described is

A --|
|------ C
B --|

Changing that to

A --|------ A1
|------ C
B --| ------ B1

clearly doesn't affect C.

Unless I need a C1 which inherits from A1, B1 and C

Sure, but that wasn't mentioned as the problem under discussion.

Your scenario could still be handled with virtual inheritance, that would
leave C1 with just one A, B, A1, B1, and C base class object. The problem,
of course, is if the A1 derivation isn't under your control, and it wasn't
made virtual.

That's true, but in the real world you can start designing structures which get
so complex that no one can understand what is going on and maintenance becomes a
nightmare.

Simple programs can solve complex problems and I think that MI does not address
this.

Jun 13 '06 #41

"Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
news:eL****************@TK2MSFTNGP03.phx.gbl...

That's true, but in the real world you can start designing structures
which get so complex that no one can understand what is going on and
maintenance becomes a nightmare.
You -can-, but that doesn't mean you must. MI can be misused more easily
than SI, it's true. But good programmers don't misuse language constructs.
As for bad programmers, I just try to keep away from them. :)
Simple programs can solve complex problems and I think that MI does not
address this.

Would you call C# a simple language? I wouldn't. Yet we both prefer it to
assembly (a very simple language indeed). Simplicity is not a virtue, in and
of itself.

That said, the one thing I don't like about composition over inheritance is
that it requires duplication. Duplication is a very simple way to solve
problems, but I don't care -- I still don't like it.

Jun 13 '06 #42

> PPS. Perhaps Radek has a comment regarding the semantic context of

multiple
candidate selection?

He's thinking about it. In his spare time, which unfortunately went missing
some years ago and he has been unable to find it. And yes Jon, I have twins
as well. And I am not as eloquent as Shawnk.

In the meantime, I'll just try to illustrate my immediate concerns (hoping
Anders is listening???)

First, the problem generally lies in the analysis/design space - not
implementation. That's not to say that an MI inspired design does not
require an MI language, but that the problem arises because the real world
patterns I see and model are sometimes orthogonal and when it comes time to
implement, I am stuck with some workaround or other due to lack of MI. The
other problem is "artificial"; when creating custom Winforms controls, I am
stuck inheriting from the Control, and I cannot also inherit from a standard
architecture.

To illustrate, I have a vast framework of business widgets, components and
objects that comprise business systems, and are all abstract - they deploy
purely as WebServices. So I have an AJAX client and a Winforms client to
consume these services. I also have (from the Gupta days) a base abstract
client-side class that "speaks" to my WebServices, with a few
abstract/virtual methods to override in concrete classes such as TextBox,
CheckBox, etc; its NOT an interface, its a class with a fair amount of code
in it. Having had to turn this elegant design into some repeated code in 20
different visual classes was painful. MI would solve it.

But still the main issue is analysis - pattern recognition - modelling and
Business Object design. Its been 6 years since I've had the luxury of MI,
and I miss it almost daily. I feel strongly that its a case of not knowing
what you're missing (like eyes or ears for someone blind/deaf since birth).

Cheers,

Radek

Jun 14 '06 #43

Shawnk

Jon,

As always it a true pleasure to read, consider and answer the conceptual
points
raised in your comments.

I thought it best to consolidate my response to your excellent points in the
hope of moving our mutual controversial opinions towards a metrically proven
theory of functional normalization.

The following will hopefully be of some small benefit to help a few OOP
programers to better understand the problem of functional normalization within
the context of current C# expression mechanisms.

I have partioned the posts in this response so each is focused on a
fundamental
aspect of our discussion.

Shawnk

PS. Thanks again for your time and contributions in helping to develop a
(hopefully) better understanding of functional normalization in OOP and C#.

Jun 14 '06 #44

Shawnk

Radek,

I can't thank you enough for excellent point regarding functional
normalization.

I always use the term 'functionally orthogonal' but your 'normalization'
comments
are a much better articulation.

With that in mind could you review my comments in response to some of Jon's
points regarding the potential for metrics to measure MI and functional
normalization?

I look forward to hearing your thoughts on this matter.

Shawnk

Jun 14 '06 #45

Shawnk

[1] Communication as an accelerant to scientific inquiry

Hopefully a PHD/Masters student will read this while
they are still considering the subject of a their disertation.

The concepts in this post are gravitaing towards a potential
software tool based on a C# parser that could analyize interfaces
(in C#) and determine the amount of 'forced code replication'.

Though still somewhat nebulous at this point the Shawnk/Cerny
position of 'MI as a inherent requirement for a functionally
normalized code base in OOP' is a concept ripe for exploration
(a shameless plug :-).

Your mission???

MI propoents could use a champion student like you (yes you!!) that can
transform what others call merely an opinion into a validated metrically
proven
fact!!!

Clearly MI propoents have a strong intutive certainty that MI is not just a
language feature but a fundamental logical expression that is inherently vital
to a concept herein called 'functional normalization' (within the context of
this
thread - term coined herein by Shawnk/Radek-Cerny comments).

Like a 'message in a bottle' (reminds me of the old Police song) this humble
post will hopefully land on the right shore. That being someone who has the
darn time Anders, Jon, I and many others do not because of prior commitments.

I believe a simple (as disertation papers/projects go) thesis based on simple
character-count/token-count (information theory) of the language expression
(and
ignoring the output of the compiler) can detect 'forced repeated fragments of
source code' in any SI-Interface based lanaguage.

Proff would be an automated refactoring of the Interface based design into a
pusedo C# (roll your own specifcation/semantics) that uses MI. And yes (IMHO)
you can ignore the compiler output BECAUSE (and this is paramount) the
target/focus of the analysis is the logic contained in the logical
expression of
the medium (that is - the source code itself).

State space collision (see thread herein) can be regulated to a configurable
modality of the analysis. The intent being that the resulting (hypothetical
output) would have logical consistentency (based on a preffered implmentation
output of the compiler).

By posting the tool on the Internet and allowing (or not) results to
be streamed to centralized web server a portion of the world C# code
base could be analyzed for 'forced code replication' phenonmena.

An important part of the anaylsis/thesis is the intellectual
breakdown of the problem space using specific conceptual terminology
such as;

[A] Mulitple Inheritance
[b] Virtual Inheritance
[C} Implementation Inheritance
[D} Functional Normalization
[E] Inherited Surface Exposure (expose parent APIs to child surface)
[F] Inheritance Threads/Lines ( Mechanism of Functional Normalization)
[G] Fully normalized code base (one with no diamond structures)
[H] Language Semantic vs Output Implemenation separation
[i] Functional Unit (state/methods to produce some computing effect)
[J] Functionally Orthogonal threads of inheritance
[-] ... other problem definition and phenomena dissolution terms

Note that prior to code and even architecture the conceptual
terminology must be defined and must transcend any given
language specification (such as the C# spec). The foundation
language of the logic being human thought (English, etc).
Thus the 'roll your own' C# spec recommendation.

Metric Focus : There exists (MI proponet position) a 'Forced Code
Replication' due to
SI-Inteface expression limit (an artifically induced 'logical expression
envelop
limit' that prevents the 'inherent functional normalization' effect of MI from
its process of normalizing functional logic in OOP expressions.

[Summary of this post and overview of this thread]

Initially this thread was a informal litmus test of SFM (Strategic Functional
Migration) capability/understanding in the C# community. An analysis of the
resulting litmus (so to speak) exhibits traces of a fundamental proposition
(IMHO) which is;

Database normalization and data replication metrics have a
fundamental similary to functional normalization metrics in OOP
(object oriented Programming) code bases.

The above thoughts are presented in the hope that our community
(C#, the .NET programming community, OOP programers in general)
could develop a formalization of functional normalization
that would provide metrics of 'forced code replication' due
to perceived inadaquacies in a purely SI-Interface approach (should they
exist).

As a counterpoint aganist MI proproents this theory/metric-set could
(hypotetically) prove that MI is not as inherent as its proponents claim.

I would like to thank the reader for taking these thoughts
into consideration as well as taking the time to go through
what is clearly a very labourious process (in reading this thread).

Shawnk (a ubiquotous and ahameless MI proponent)

PS. I do this to better understand C#/C++ architecture tradeoffs.

PPS. I can later use this in executive/engineering disertations

Jun 14 '06 #46