I would like to proposed
the following specification for Mixins be included as part of Version 1.0
D Programming Language
specification. All comments are welcomed.
MIXINS SPECIFICATION
Version 0.1
Introduction
What are mixins ?
A mixin is a class-like entity whose methods/fields are mixed-in to
the mixing class just
as if the author of that class had written them manually.
The rational for Mixins is quite compelling...
One of the greatest shortcomings of the C++ language from a
Object Oriented perspective,
is that there is no
language support for Aggregated Objects. As such, Aggregation has to be
performed programatically, often
(incorrectly) using the inheritance mechanism as a
coding
shortcut. By including language support we provide a direct
correlation between OOD using
modeling techniques like UML, and OOP.
Background
Please read the following;
Lexical
I propose that we use one of the two remaining (common)
symbols, i.e. # and @ as well as
the keyword mixin. For this document we'll use # as the
mixin symbol
Syntax
There are a number of syntax alternatives that could be
incorporated.
class <identifier> [:
<inherited-class>]
[# <aggregated-class> <local-identifier>]*
For example;
class Lamp : Light
#
Body
cBody
#
Switch cSwitch
# Globe
cGlobe
#
PowerCord cPowerCord
{
this() {
super();
cBody();
// Body construction
cGlobe();
// Globe construction
cPowerCord();
// PowerCord construction
cSwitch(cGlobe,cPowerCord); // Switch
construction
}
};
Alternative B:
class <identifier> [:
<inherited-class>]
[# <aggregated-class> <local-identifier>
[,
<aggregated-class> <local-identifier>]*]
For example;
class Lamp : Light
#
Body cBody
, Switch cSwitch
, Globe
cGlobe
, PowerCord
cPowerCord
{
this() {
super();
cBody();
// Body construction
cGlobe();
// Globe construction
cPowerCord();
// PowerCord construction
cSwitch(cGlobe,cPowerCord); // Switch
construction
}
};
Semantics
The rules for Mixin variables should be the same as class
member declarations, except
Mixins allow the interfaces of the aggregated class to be
included as part of the mixing class.
This fact means that it is possible to have multiple
versions of the same member name
within a mixing class.
I propose a simple precedence rule, where the member defined
in the class overrides those
defined in the aggregated class, and those in the aggregated
classes are assigned according
to the order they are declared. If this was to take place, a
compiler warning message stating
"that member X of aggregated class A is taking precedence over that in aggregated class B"
should be displayed in the error
log.
Note: there are probably other things that will need to be
considered here !
Conclusion
Mixins permit externally declare classes to be
used as part of a class, and in so doing provides
a real alternative to the Multiple Inheritance option provided for in the
C++ language. As such, this
relatively insignificant addition to the language
should greatly enhance the overall flexibility of the
D Programming Language.
Comments !