Timeline for The dilemma of implementing virtual inheritance
Current License: CC BY-SA 4.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 19, 2023 at 20:47 | comment | added | Caleth | @curiousguy yes, that's what i said | |
| Apr 16, 2023 at 1:39 | comment | added | curiousguy | @Caleth "In Java, there is no multiple inheritance of fields, so this doesn't arise" In Java there is no multiple inheritance of classes but there is for interfaces, which are indeed virtual base like. Because Java interfaces have no data members (unlike C++ where even ABC, Abstract Base Classes, can have data), multiple inheritance of the same variable via diff paths doesn't come up; because interfaces have no state and no ctors, a lot of the implementation complexity of virtual bases (which is specifically linked order of construction and dynamic type when in c/d-tors) never comes up. | |
| Nov 27, 2018 at 22:59 | comment | added | curiousguy | It would help if you could define the kind of "bad software design" you want to avoid (and if you could name those languages that don't have virtual inheritance). | |
| Nov 27, 2018 at 22:56 | comment | added | curiousguy | @amon "If your language (...) does not use fixed object layouts (instead of, e.g., hash tables) then virtual inheritance is inapplicable" How can different implementation details suppress the need for a language feature? | |
| Nov 27, 2018 at 22:48 | comment | added | curiousguy | @FrankHileman You can have virtual methods in a non virtual base class. | |
| Jul 21, 2018 at 1:12 | answer | added | Jules | timeline score: 0 | |
| Jul 14, 2018 at 12:02 | answer | added | amon | timeline score: 3 | |
| Jul 11, 2018 at 16:03 | comment | added | Frank Hileman | @dtech You can get these types of advantages without inheritance, as long as you have a way to bundle members of an API and reference that bundle in multiple places. | |
| Jul 11, 2018 at 16:01 | comment | added | Frank Hileman | If you get rid of virtual inheritance, get rid of inheritance, and add delegation. Inheritance is not especially useful without virtual methods. | |
| Jul 11, 2018 at 13:18 | review | Close votes | |||
| Jul 17, 2018 at 3:02 | |||||
| Jul 11, 2018 at 12:48 | history | edited | dtech | CC BY-SA 4.0 |
added 297 characters in body
|
| Jul 11, 2018 at 12:42 | history | edited | dtech | CC BY-SA 4.0 |
added 297 characters in body
|
| Jul 11, 2018 at 12:39 | comment | added | dtech | @shawnhcorey I won't be hasty to dis anything, nothing is intrinsically good or bad. Even complexity can be good when the returns are worth it. | |
| Jul 11, 2018 at 12:33 | comment | added | shawnhcorey | @dtech And inheritance is more under the programmer's control. Don't dis verbosity. Making things explicit clears up a lot of fuzzy thinking. | |
| Jul 11, 2018 at 12:24 | comment | added | dtech | @amon I'd say that this is the entire motivation behind virtual inheritance. But if we are to take the wikipedia article example, I'd say it is bad design for winged animal to inherit animal, it should be an interface applied to an animal that only contains the additional stuff, therefore eliminating the member duplication entirely. And I already have requirements for inheritance implemented, so a winged animal can use animal without inheriting it and mandate that any use of the interface comes with the direct or indirect inheritance of an animal. | |
| Jul 11, 2018 at 12:18 | comment | added | amon | Please consider the constraints why a C++ implementation may use virtual inheritance: when inheritance works by embedding the base object layout into the subclass layout, virtual inheritance can avoid embedding a common base multiple times in case of multiple inheritance. If your language doesn't support MI or does not use fixed object layouts (instead of, e.g., hash tables) then virtual inheritance is inapplicable. For an alternative consider MI in Python, or trait systems without data member inheritance. Please edit your question with more context about your language. | |
| Jul 11, 2018 at 12:15 | comment | added | dtech | @shawnhcorey so inheritance with different semantics just, eh? ;) And more verbose too. | |
| Jul 11, 2018 at 12:14 | comment | added | shawnhcorey |
@dtech I would say the language should be designed to forward methods. Car::start is Vehicle::start Same parameters and return values.
|
|
| Jul 11, 2018 at 12:10 | comment | added | dtech |
@shawnhcorey I'd say it has its benefits. There is the conceptual benefit of being able to say that a car is a vehicle than to say a car has a vehicle. There is the syntax advantage too, you can just car.start() rather than car.vehicle.start(). For buttons that is extreme overkill, I favor the solution where buttons use signals to implement the desired functionality rather than to subclass each and every button. A subclass is only justified if you change the class or add to it. What a button does can and should be external code, not part of the button.
|
|
| Jul 11, 2018 at 12:07 | comment | added | Caleth | C++ has it because, among other things, an object is the bytes that make up it's members and bases. In Python, members are all references, and all inheritance is "virtual". In Java, there is no multiple inheritance of fields, so this doesn't arise | |
| Jul 11, 2018 at 12:06 | comment | added | shawnhcorey |
I question the need for inheritance at all. Only rarely is it ever needed. An eye-opener is Perl/Tk which uses has_a relationships rather than the traditional is_a of most GUIs. For example, to put a button on a dialog box, you would say my $btn = $dlg->Button( %some_parameters ); No need to create a class MyDialogButton which inherits from the Button class. Ever button is an object of the Button class; it just their parameters that cause different behaviour.
|
|
| Jul 11, 2018 at 11:47 | history | asked | dtech | CC BY-SA 4.0 |