Traditional namespacing and scoping behaviors in familiar programming languages gives a nice way to disambiguate. Also, if a named scope is identified as an interface (abstract base class), it can be implemented or inherited.
However, such approaches have some drawbacks:
In order to inherit, you have to import/depend upon an abstract description of the interface, which may be in another code package that changes outside your control. Go gets around this by having implicit interfaces. I want this feature, although I also want to be able to (optionally) declare an inheritance relationship to force the compiler to prove compatibility. Also, I want inheritance/implementation of subset interfaces (see http://codecraft.co/2008/08/19/decoupling-interfaces-as-versions-evolve-part-3/).
Inheritance is all or nothing. In the real world, inheritance can be more complex; a liger may not inherit tiger stripes from its parent because inheritance suppresses recessive genes.
As an alternative to inheritance, you can contain/subsume (create a data member that is embedded inside). However, this forces a name hierarchy. bouquet CONTAINS rose, and any attributes of a rose are accessible with an additional level of dereference: bouquet->rose->scent. This extra level of dereference tends to make code more verbose. In normal human language, we say "Replace the car's fan belt" even though the fan belt is actually a part of the engine contained in the car.
A particular data member can only be a member of a single interface or grouping.
Data members may have a similar purpose or aspect, but not identical manifestation. For example, a car has a steering wheel, a motorcycle has handlebars, a boat has a helm, and a plane has a stick. We need a way to map data members from some implementing class to an interface's more general term ("in a car, steering_wheel ==> steering_mechanism, whereas in a motorcycle, handlebars ==> steering_mechanism"), without writing wordy boilerplate wrapping functions.
I'd like to be able to cluster members (data members or methods) into a group (imagine the "appearance" group for a "car" object consisting of "paint", "cladding", "window tinting"), where the same item can be a member of more than one group ("paint" could also be a part of "manufacturer options", "window tinting" could also be a part of "after-market mods"). Putting an item into a group would provide an optional namespace (car->appearance->paint and car->paint and car->manufacturer_options->paint all refer to the same thing). Groups might be layer-able (after-market mods hides any same-named items that were part of the original car from the manufacturer). Additional semantics could attach to groups (you could inherit them or include them [reuse without forced hierarchical name containment], implement them or hide them or make them read-only or mark them in other ways).
Consider the idea of aliasing (separate issue, but related) to rename a data member that's been inherited.
Also, is there a way to selectively inherit (we assume you can override base class virtual methods, but what about dropping useless data members (would have to prove that no method needs them anymore). Would we basically create a union between new member in derived class and unused member in base class?
Traditional namespacing and scoping behaviors in familiar programming languages gives a nice way to disambiguate. Also, if a named scope is identified as an interface (abstract base class), it can be implemented or inherited.
However, such approaches have some drawbacks:
I'd like to be able to cluster members (data members or methods) into a group (imagine the "appearance" group for a "car" object consisting of "paint", "cladding", "window tinting"), where the same item can be a member of more than one group ("paint" could also be a part of "manufacturer options", "window tinting" could also be a part of "after-market mods"). Putting an item into a group would provide an optional namespace (car->appearance->paint and car->paint and car->manufacturer_options->paint all refer to the same thing). Groups might be layer-able (after-market mods hides any same-named items that were part of the original car from the manufacturer). Additional semantics could attach to groups (you could inherit them or include them [reuse without forced hierarchical name containment], implement them or hide them or make them read-only or mark them in other ways).
Consider the idea of aliasing (separate issue, but related) to rename a data member that's been inherited.
Also, is there a way to selectively inherit (we assume you can override base class virtual methods, but what about dropping useless data members (would have to prove that no method needs them anymore). Would we basically create a union between new member in derived class and unused member in base class?