Strategic Functional Migration and Multiple Inheritance

[Guest]

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

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#.

 

[Guest]

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/Inheritance_(computer_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/Interface_(computer_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

 

[Guest]

Continued Post : Strategic Functional Migration and Multiple Inheritance

Example of 'Strategic Functional Migration' : SFM

Pattern [A] - Extended Event Observer : Client, Subject, Observer, Binder,
Event_Recorder, Event_log, Event_Viewer

Pattern - State Machine ----------: Machine, Switch, Map, ------------
State_Recorder, State_log, State_Viewer

The common 'logging/logger' code is factored out.

A new 'Logger Pattern' is formed for histories, logs, etc. - which includes.

Item, Log, Recorder, Viewer, Binder (to bind base roles together into a
'logger' entity - (pattern stage))

---- code reuse result via II (Implementation Inheritance) -------

Patterns A/B use a generic 'logger' entity based on <_itm_typ> as
_Evt_typ/_Sta_typ

==== KEY DIFFERENCE OF VIRTUAL INHERITANCE (intefaces) VS IMPLEMENTATION
INHERITANCE ==========

Pattern A/B logger roles can STILL INHERIT from other ESSENTIAL BASE CLASSES

----- Key point by definition ------------------

SFM (Strategic Functional Migration) requires functionally orthogonal
decomposition of 'replicated code'.

Decomposition must not effect or require pre-existing (pre decomposition) base
class inheritance changes.

----- Key point example ---(pre/post decomp) ---

II = Implementation Inheritance
MI = Multiple Inheritance
VI = Virtual Inheritance

Pre Decomp Pattern A/B

- Both had a 'debug/tracer' base class based on a Tracer debug pattern

Post Decomp Pattern A/B

With II ....

Tracer and Logger patterns are separate and remain functionally orthogonal

Without II using VI (as in C#) ....

Tracer and Logger patterns must be combined and then inherited as a 'super
logger with tracing' entity

------ core competency code point --------------

The functionally orthogonal nature of core competency code requires the 'mix
and
match' of the core role models (pattern participants) which provide the
functional archetypes of the core functions (the IP - Intellectual property).

Thus (and therefore) SFM (Strategic Functional Migration) is ONLY possible
with
MI/II language features.

Note : Arguments proposing 'Mixins and other contrived workarounds' (as an
alternative SFM mechanism to II) prove the ignorance of the proposer in:

(A) SFM itself
(B) analytical metrics comparing different SFM mechanisms
(C) Formal comparative analysis of different SFM mechanisms

The prevelance of such SFM implementation arguments (or responses) is an
informal indicator of the point spread (level of target community ignorance)
relative to SFM, core competency, strategic investment, IP (intellectual
property) and other executive engineering level issues.

Shawnk

PS. Personally I concede that the logger/trace entity (above) integration
approach (SFM, etc) can be argued (MI-II not needed,
VI-SII is fine).

To extend this and argue that (thus and therefore) ALL entities can be
integrated into SUPER-entities is incorrect. Everything would end up as one
big
super entity.

Such arguments are based on not understanding II, SFM, functional
orthogonality, MI
and strategic code reuse.

Ultimately, all 'super-entity' code reuse arguments are founded on ignorance
of
SFM and can not (logically) exist without this ignorance.

PPS.

Since such arguments (SUPER-entities) are prevalent in the community by
'expert'
pundits, we can infer that the target programming community is;

[1] Predominantly ignorant of 'Strategic Functional Migration' (SFM)
(and/or)
[2] The target community has not evolved to the point of recognizing SFM AND
'moved to a language' that supports it.
OR
[3] SFM (Strategic Functional Migration) is not an inherent/desirable
phenomena/mechanism of code reuse

So: if [3] then [1] and/or [2]

The pragmatic/real world/logical wrap around is;

[1] Ignorance : results in the pragmatic (but not theoretically true) [3]
[2] Evolution : results in the pragmatic (and --- theoretically true) [3]

based on [3] being theoretically (objectively) true.

The logical 'core focal point' of the argument is:

[X] Subjective : Programming community understanding of SFM as a 'pattern
refactor mechanism'

[Y] Objective : Inherient utility and structural reality (objective truth)
of SFM as a 'pattern refactor mechanism'

Thus the question on entry to this discussion,

" What percentage of the target community is GOOD at SFM? "

Projection : To argue SFM based on other (non-II) mechanisms is ultimately
an attempt to display [1] or prove [3]

---------------

Caveat : [2-B] - ...moved to a langague

CURRENTLY there is no (production ready - prime time) language that supports C
like syntax, C# productivity and C++ II (that we can agree on . If there
was
(such a language) then, it can be argued, that the community has already
evolved
and merely waiting for a solution to migrate to. If any one knows of such a
language please respond (Efiel, etc).

 

[Nicholas Paldino [.NET/C# MVP]]

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?

 

[Guest]

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

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]
- (e-mail address removed)

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

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#.

 

[Radek Cerny]

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

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#.

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]
- (e-mail address removed)

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

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#.

 

[Guest]

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....

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

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#.

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]
- (e-mail address removed)

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

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#.

 

[Radek Cerny]

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.

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....

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

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#.


:

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]
- (e-mail address removed)

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

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#.

 

[Jon Skeet [C# MVP]]

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.

 

[Guest]

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

 

[Guest]

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.

 

[Radek Cerny]

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

 

[Guest]

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

 

[Jon Skeet [C# MVP]]

<snip>

I don't have much time (twins upstairs...) so I'm just going to pick up

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.

 

[Radek Cerny]

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]]

I'll now have to pick on a few of your points...
Firstly
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,

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 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.

 

[Saad Rehmani]

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/Inheritance_(computer_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/Interface_(computer_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

 

[Mark Wilden]

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

 

[Saad Rehmani]

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

 

[Mark Wilden]

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