Multiple Inheritance
BlitzMax Forums/BlitzMax Programming/Multiple Inheritance
| ||
| is there a way? Is it to hard for mark to add? Has he said anything about it? I think it'll benefit us all to have this feature. Having more than one "is-a" relationship will make things go so much smoother. I know there's other ways, it's just takes more work than should be necessary. |
| ||
| Can't be done. |
| ||
| I know there's other ways, it's just takes more work than should be necessary. It's also less of a headache. Swings and roundabouts. |
| ||
| It is hard to add ... Multiple inheritance has some must haves that are the hard thing: Selection mechanisms if 2 classes define the same function names Renaming mechanisms to rename functions inherited undefining mechanisms to undefine functions inherited and the same for fields, globals etc as well ... Its sadly no trivial task to make multiple inheritance nice and smooth (C++ is no good example on how to do it, it lacks some stuff as well) |
| ||
| Why does Multiple Inheritance have to allow that both parent types have globals/fields/function/methods with the same name? Seems to me it is to just give a compile error if any of the types inherited have any naming conflicts, or? |
| ||
| "Multiple inheritance can cause some confusing situations, so there is some debate over whether or not its benefits outweigh its risks. Java compromises: it allows a class to inherit interfaces from more than one parent (that is, one can specify that a class inherits all the types from its parents and must have all of the same externally exposed methods of its interface-parents, and allow the compiler to enforce that), but can inherit implementation (methods and fields) from only one parent. Microsoft's .NET languages such as C# and Visual Basic implement this interface approach as well." http://en.wikipedia.org/wiki/Multiple_inheritance |
| ||
Or... an implementation that is similar to a cross between Python and Eiffel would be pretty good...
Type ClassA Inherits ClassB, ClassC
...
End Type
By default, name conflicts are resolved in left-to-right order... i.e. on execution, methods on the object are searched first in ClassA, then ClassB and ClassC Defining aliases and/or wrapping Methods with base calls allows the inheriting object to fine tune the name collisions:
Type ClassA Inherits ClassB, ClassC
MethodAlias MethodXFromC:ClassC.MethodX
Method MethodX()
some code here
End Method
Method CallABaseMethod()
ClassB.SomeMethod()
End Method
...
End Type
The above class would have a callable method named "MethodXFromC" which maps to the "MethodX" method of Class C. Since ClassA defines MethodX, the default left-to-right search would give it precedence. The alias would still keep ClassC's version available. I don't think this implementation would fully eliminate the dangers associated with multiple inheritance on 2 classes that inherit from the same base, but it would minimize it. Especially if aliased methods could hook back several layers deep. |
| ||
| I don't think there's anything too semantically tricky about MI. The compiler can always demand that any 'same method' identifiers are resolved. But 'multimethoids' is better, and taken to it's ultimate conclusion, multimethods clashes with 'objects', in that it implies that 'work' resides outside the 'data'. This is radically anti-OO, and I totally agree with it! Next...! |
| ||
| I thought "multi-method" was basically a way of implementing function overloads for loosely-type languages. (which wouldn't be a horrible implementation on it's own) I can see where you're going, but as you said, it sort of blows the idea of encapsulation out the window. The real problem with doing "inheritance" that way is that it doesn't scale very well if you force it to co-exist within an object oriented implementation. anti-OO is an understatement. It would fight it tooth and nail :) To ensure complete scalability, objects have to be merely field-only containers and ALL "methods" defined outside of that. If you dared to keep methods in the objects, you'd have to break consuming applications by busting the conflicting method out of the objects at any point of development where there's a clash. You're correct though... It certainly does solve the base problem of method collisions, and it's a very interesting work-around for creating something that "sort of" behaves like multiple inheritance. |
| ||
| The compiler can always demand that any 'same method' identifiers are resolved. So if you want to use two different 3rd party libraries that just happen to both have an update() or render() function, you're screwed? Doesn't sound like much of a solution.Interfaces is the way to go. |
| ||
| Interfaces is indeed the way to go. |
   |