At 08:47 2017-05-22, Alan Bourke <alanpbourke(a)fastmail.fm> wrote:
>On Mon, 22 May 2017, at 03:07 PM, Stephen Russell wrote:
>
> > Why would you want to do it is my question?
>
>I would say being able to implement multiple interfaces as in C# is
>perfect for almost any use case and various design patterns using
>interfaces would cover any unlikely situations where multiple
>inheritance would be a good idea.
Multiple inheritance sounds, at first, to be something that
could be useful, but then, you run into the problem of which parent
wins if both have a method or property of the same name. How would
you handle this?
Well, then, do not do that.
I am a sensible person, and I would not do that. You might
well be one, too. We both know that there are those who would climb
Everest with it. (Because it's there.)
I remember a similar fight when I was defining my form
handling. I have two pairs of classes that are very similar. Here
is the heading code for them:
***** Start of Code *****
* atgettext Class
* @ ... get Equivalent Class (textbox)
#define ATGETCLASSNAME atgettext
#define ATGETPARENTCLASSNAME textboxbf
* Last Modification: 2013-05-23
*
* atgettext:: and atgetedit:: are practically identical. If you make
* any changes to one, you will probably have to make them to the other. Oh,
* for multiple inheritance (not that would not create its own headaches).
*
* As of 2007-05-03, the code *should* be identical except for the title
* lines and the #define lines. The classes have been written to be nearly
* identical by checking on the base class for some actions. This bloats the
* classes just a bit, but makes it very easy to copy changes between the two
* classes.
define class ATGETCLASSNAME as ATGETPARENTCLASSNAME
#undef ATGETCLASSNAME
#undef ATGETPARENTCLASSNAME
...
enddefine
* atgetedit Class
* @ ... get Equivalent Class (editbox)
#define ATGETCLASSNAME atgetedit
#define ATGETPARENTCLASSNAME editboxbf
* Last Modification: 2013-05-23
*
...
define class ATGETCLASSNAME as ATGETPARENTCLASSNAME
#undef ATGETCLASSNAME
#undef ATGETPARENTCLASSNAME
...
enddefine
* textboxbf Class
* Basically Formatted textbox
#define BFCLASSNAME textboxbf
#define BFPARENTCLASSNAME textbox
* Last Modification: 2014-11-17
*
* textboxbf:: and editboxbf:: are practically identical. If you make
* any changes to one, you will probably have to make them to the other. Oh,
* for multiple inheritance (not that would not create its own headaches).
*
* As of 2004-07-21, the code *should* be identical except for the title
* lines and the #define lines. The classes have been written to be nearly
* identical by checking on the base class for some actions. This bloats the
* classes just a bit, but makes it very easy to copy changes between the two
* classes.
...
define class BFCLASSNAME as BFPARENTCLASSNAME
#undef BFCLASSNAME
#undef BFPARENTCLASSNAME
...
enddefine
* editboxbf Class
* Basically Formatted editbox
#define BFCLASSNAME editboxbf
#define BFPARENTCLASSNAME editbox
* Last Modification: 2014-11-17
...
define class BFCLASSNAME as BFPARENTCLASSNAME
#undef BFCLASSNAME
#undef BFPARENTCLASSNAME
...
enddefine
***** End of Code *****
Initially, the pairs of classes were just about identical since
textbox and editbox have very similar functionality. I ended up
making them identical so if I had to change one, I could change the
other easily. Both pairs of classes have the same code.
My atgettext and atgetedit classes differentiate by checking
the declared type of the data value. The type declaration is in my
form generation file; if not a memo, use atgettext; if a memo, use atgetedit.
My textboxbf and editboxbf classes differentiate by testing of
.baseclass at various points.
It would have been shorter if VFP allowed one to #include
executable code and have it stick. (VFP does allow #include'ing of
executable code, but it ignores it.)
Sincerely,
Gene Wirchenko