D - Mixin ?
- fred (1/1) Apr 19 2004 Is Mixins planned for the version 1.0 release ?
- Matthew (6/7) Apr 20 2004 Nothing definite AFAIK, but I think I'm going to need them for DTL, so m...
- fred (2/4) Apr 20 2004 What's DTL ?
- Ilya Minkov (8/9) Apr 20 2004 Da Tamplate Loom - it would be a huge loom spun by thousands of ants
- Kris (8/17) Apr 20 2004 LOL :-)
- Matthew (9/18) Apr 20 2004 LOL!
- John Reimer (2/15) Apr 20 2004 Ha ha! That was actually kind of funny, eye. :-D
- Warren (7/8) Apr 20 2004 charset="Windows-1252"
- J C Calvarese (10/15) Apr 20 2004 Here's one explanation (although D's templates have changed since it was...
- fred (5/13) Apr 20 2004 That's my interest in them...
- Matthew (12/13) Apr 21 2004 Ruby (and, I hope, D): A mixin is a class-like entity whose methods/fiel...
- fred (103/109) Apr 22 2004 Apologies if some of this seems bleeding obvious, but I hope it may add ...
- Patrick Down (76/106) Apr 23 2004 Fred, I agree 100% with you about aggregation not having
- fred (140/161) Apr 23 2004 boundary="----=_NextPart_001_1220_01C429ED.009F62D0"
Nothing definite AFAIK, but I think I'm going to need them for DTL, so maybe we can persuade big W of the need. It'd be good if we could stimulate a good debate on the issue. Thoughts, anyone ... ? "fred" <info fleet-manage.com> wrote in message news:c625pc$6np$1 digitaldaemon.com...Is Mixins planned for the version 1.0 release ?
Apr 20 2004
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:c643s7$qqa$1 digitaldaemon.com...Nothing definite AFAIK, but I think I'm going to need them for DTL, so maybe we can persuade big W of the need.What's DTL ?
Apr 20 2004
fred schrieb:What's DTL ?Da Tamplate Loom - it would be a huge loom spun by thousands of ants running in a wheel to make D templates automatically, for every occasion. Perhaps it could also write magazine articles and books for Mathew, compilers for Walter and so on. You just need to add another wheel. We could also use squirrels and rabits, if we were to make something even bigger. khmm khmm
Apr 20 2004
"Kris" <someidiot earthlink.dot.dot.dot.net> LOL :-) Monty Python: "Well; we could build this great big Badger, then Lancelot and I would *leap* out and ..." Fred; it would certainly be easier for you to catch up if there were a "search" tool available for the web interface. However, you might try one of the free Nescape news-readers instead? DTL is intended to be STL for D ... "Ilya Minkov" <minkov cs.tum.edu> wrote in message news:c64f4u$1drm$1 digitaldaemon.com...fred schrieb:What's DTL ?Da Tamplate Loom - it would be a huge loom spun by thousands of ants running in a wheel to make D templates automatically, for every occasion. Perhaps it could also write magazine articles and books for Mathew, compilers for Walter and so on. You just need to add another wheel. We could also use squirrels and rabits, if we were to make something even bigger. khmm khmm
Apr 20 2004
LOL! I was going to go into a big explanation about a single code-base for compile-time and runtime polymorphism, selected by template parameterisation, and supporting 3+N enumeration models, but now I don't need to bother. One thing I would disagree with you, however, is that I see the loom powered by hundreds of fat guinea pigs. "Ilya Minkov" <minkov cs.tum.edu> wrote in message news:c64f4u$1drm$1 digitaldaemon.com...fred schrieb:What's DTL ?Da Tamplate Loom - it would be a huge loom spun by thousands of ants running in a wheel to make D templates automatically, for every occasion. Perhaps it could also write magazine articles and books for Mathew, compilers for Walter and so on. You just need to add another wheel. We could also use squirrels and rabits, if we were to make something even bigger. khmm khmm
Apr 20 2004
Ilya Minkov wrote:fred schrieb:Ha ha! That was actually kind of funny, eye. :-DWhat's DTL ?Da Tamplate Loom - it would be a huge loom spun by thousands of ants running in a wheel to make D templates automatically, for every occasion. Perhaps it could also write magazine articles and books for Mathew, compilers for Walter and so on. You just need to add another wheel. We could also use squirrels and rabits, if we were to make something even bigger. khmm khmm
Apr 20 2004
charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What's a mixin? I presume fred meant to ask "Are mixins planned..." "fred" <info fleet-manage.com> wrote in message = news:c625pc$6np$1 digitaldaemon.com...Is Mixins planned for the version 1.0 release ?
Apr 20 2004
Warren wrote:What's a mixin? I presume fred meant to ask "*Are *mixins planned..."Who are we, the grammar police? ;)"fred" <info fleet-manage.com <mailto:info fleet-manage.com>> wrote in message news:c625pc$6np$1 digitaldaemon.com... > Is Mixins planned for the version 1.0 release ?Here's one explanation (although D's templates have changed since it was written, so the syntax might be a little off): http://www.digitalmars.com/drn-bin/wwwnews?D/9093 I get the impression it's something of a replacement for multiple inheritance (since D doesn't have MI). -- Justin http://jcc_7.tripod.com/d/
Apr 20 2004
That's my interest in them... My gut feel (FWIW) is that to attract the wider C++ community, there is a need to provide a viable alternative to MI, which Mixins seems to represent. If this feature were to be excluded from the base (1.0) release, this would be ammunition for those MI die-hards to shun what seems to be the first progressive step forward to the C/C++ language for the past decade. By porting some of the common frameworks and possibly OS's to D and it will no doubt generate a life of its own."fred" <info fleet-manage.com <mailto:info fleet-manage.com>> wrote in message news:c625pc$6np$1 digitaldaemon.com... > Is Mixins planned for the version 1.0 release ?Here's one explanation (although D's templates have changed since it was written, so the syntax might be a little off): http://www.digitalmars.com/drn-bin/wwwnews?D/9093 I get the impression it's something of a replacement for multiple inheritance (since D doesn't have MI).
Apr 20 2004
Ruby (and, I hope, D): 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. C++: A mixin class is a non-primary base class, which generally provides only types and static & non-virtual methods. (If it contains fields / virtual methods, it's a fully fledged base class, IMO) "Warren" <warrens seanet.com> wrote in message news:c647qp$11vo$1 digitaldaemon.com... What's a mixin? I presume fred meant to ask "Are mixins planned..." "fred" <info fleet-manage.com> wrote in message news:c625pc$6np$1 digitaldaemon.com...Is Mixins planned for the version 1.0 release ?
Apr 21 2004
Apologies if some of this seems bleeding obvious, but I hope it may add to the
discussion.
From what I was taught, there are two primary types of relationships in OOP:
"is-a" and "has-a" or Inheritance and Aggregation.
// Inheritance Example
class Parent {
public:
Parent() {}
void DoSomething() {/* does something */}
}
class Child : public Parent {
public:
Child() : Parent() {}
void DoSomethingElse() {/* does something else */}
}
void main()
{
Child child;
child.DoSomething(); // call to parent's method
child.DoSomethingElse(); // call to child's method
}
// Aggregation Example
class Body {
public:
Body() {}
};
class Switch {
public:
Switch() { bState = false; }
void Toggle() { !bState; }
bool State() { return bState; }
private:
bool bState;
};
class Globe {
public:
Globe() { bState = false; }
void Illuminate( bool state ) { bState = state; }
bool IsOn() { return bState; }
private:
bool bState;
}
class PowerCord {
public:
PowerCord() {}
};
// Parent class
class Light {
public:
Light() {}
};
class Lamp : public Light {
public:
Lamp() : Light(), cBody(), cSwitch(), cGlobe(), cPowerCord {}
void Toggle( bool state ) { cSwitch.Toggle( state ); }
bool State() { return cSwitch.State(); }
void Illuminate( bool state ) { cGlobe.Illuminate( state ); }
bool IsOn() { return cGlobe.IsOn(); }
private:
Body cBody;
Switch cSwitch;
Globe cGlobe;
PowerCord cPowerCord;
}
void main()
{
Light lamp = new Lamp();
if( DarkOutside() && !lamp.IsOn())
{
// require User Input here
lamp.Toggle()
lamp.Illuminate( lamp.State())
}
}
Unfortuantely, the C++ language only supports the former (Inheritance) through
the ":"
operator, whereas the later (Aggregation) does not have the same syntatical
support.
As such, many programmers (wrongly, to the purists) use the Inheritance
mechanism
to perform Aggregation operations, since it saves on coding through not having
to
redirect methos of subordinate components.
For Example; the following produces the same outcome on the earlier main()
program.
class Lamp : public Light,
public Body,
public Switch,
public Globe,
public PowerCord
{
public:
Lamp() : Light(), Body(), Switch(), Globe(), PowerCord {}
}
This is where I think Mixins can add a great deal of value. For example;
class Lamp : public Light,
mixin Body cBody,
mixin Switch cSwitch,
mixin Globe cGlobe,
mixin PowerCord cPowerCord
{
public:
Lamp() : Light(), cBody(), cSwitch(), cGlobe(), cPowerCord {}
}
This is about as lightweight as using multiple inheritance equivilant, and has
the same
advantage of not having to redefine all the methods from aggregated components.
I haven't thought this solution through properly, so excuse me if it appears
somewhat haphazard.
Comments ???
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c678mi$4mt$1 digitaldaemon.com...
Ruby (and, I hope, D): 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.
C++: A mixin class is a non-primary base class, which generally provides only
types and static & non-virtual methods. (If it contains fields / virtual
methods,
it's a fully fledged base class, IMO)
Apr 22 2004
In article <c6ae9f$2cfh$1 digitaldaemon.com>, fred says...Apologies if some of this seems bleeding obvious, but I hope it may add to the >discussion.Good discussion is always welcome. See comments below.Unfortuantely, the C++ language only supports the former (Inheritance) through the ":" operator, whereas the later (Aggregation) does not have the same syntatical support. As such, many programmers (wrongly, to the purists) use the Inheritance mechanism to perform Aggregation operations, since it saves on coding through not having to redirect methos of subordinate components. For Example; the following produces the same outcome on the earlier main() program. class Lamp : public Light, public Body, public Switch, public Globe, public PowerCord { public: Lamp() : Light(), Body(), Switch(), Globe(), PowerCord {} } This is where I think Mixins can add a great deal of value. For example; class Lamp : public Light, mixin Body cBody, mixin Switch cSwitch, mixin Globe cGlobe, mixin PowerCord cPowerCord { public: Lamp() : Light(), cBody(), cSwitch(), cGlobe(), cPowerCord {} } This is about as lightweight as using multiple inheritance equivilant, and has the same advantage of not having to redefine all the methods from aggregated components. I haven't thought this solution through properly, so excuse me if it appears somewhat haphazard. Comments ???Fred, I agree 100% with you about aggregation not having the same versatility as inheritance. In fact I tend to think that inheritance tends to make programmers think in term of hierarchies where they are not necessarily appropriate. For example: Vehicle -Car --Sports car --Station Wagon -Truck While this hierarchy might be appropriate for organizational purposes you don't build a sports car by modifying some abstract concept of a Vehicle you build it by putting together specific types of components. Sports Car: implements a Vehicle interface and is made up of high performance engine, sleek frame, two seats, manual transmission Station Wagon: implements a Vehicle interface and is made up of ordinary engine, long frame, two bench seats, cargo space, automatic transmission, wood paneling etc... When I think about building software I tend to think less in terms of hierarchies and more in terms of interfaces and building blocks. The thing about build blocks is that you usually have ways of connecting them together. Right now for C++ and D this is a rather manual process. You aggregate all your building blocks into a class and then add functions to the class to expose the functions of the building blocks outside of the class and to wire together various functions of the building blocks to each other. With your mixin example to have hit on the one problem of exposing the functions of the building blocks outside of the class. I'd like to address wiring together various functions of the building blocks to each other Let take your example and go a little farther with it. I'm playing with some syntax here: interface PowerSource { void DrawPower(bool); } interface PowerSink { void UsePower(bool); } class Switch(source : PowerSource, sink : PowerSink) { public: Switch() { bState = false; } void Toggle() { bState = !bState; source.DrawPower(bState); sink.UsePower(bState);} bool State() { return bState; } private: bool bState; }; class PowerCord : PowerSource { public: PowerCord() {} void DrawPower(bool); }; class Globe : PowerSink { public: Globe() { bState = false; } void Illuminate( bool state ) { bState = state; } bool IsOn() { return bState; } void UsePower(bool bState) { Illuminate(bState); } private: bool bState; } class Lamp : public Light { public: Lamp() {} private: mixin Body cBody; mixin Switch cSwitch(cPowerCord,cGlobe); mixin Globe cGlobe; mixin PowerCord cPowerCord; } Thus Switch becomes a mixin that can control anything with the correct interface
Apr 23 2004
boundary="----=_NextPart_001_1220_01C429ED.009F62D0" ------=_NextPart_001_1220_01C429ED.009F62D0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "Patrick Down" <Patrick_member pathlink.com> wrote in message = news:c6bg2p$146t$1 digitaldaemon.com... Good expansion of the code Patrick, as it shows how process can flow = though the aggregated objects, however, there is one thing I would like to comment = on.cPowerCord() {}class Lamp : public Light, mixin Body cBody, mixin Switch cSwitch, mixin Globe cGlobe, mixin PowerCord cPowerCord { public: Lamp() : Light(), cBody(), cSwitch(cPowerCord,cGlobe), cGlobe(), =Versus}class Lamp : public Light { public: Lamp() {} =20 private: mixin Body cBody; mixin Switch cSwitch(cPowerCord,cGlobe); mixin Globe cGlobe; mixin PowerCord cPowerCord; }Originally, I too had the your later syntax, but changed it the the = former for the reasons; 1. Most object diagrams show aggregated objects as external objects, = not internal. For example; 2. In your example, you have placed (correctly may I say) the = aggreagated objects as private.=20 However, the code is accessing methods of these objects as though = they were public.=20 By placing the object declarations outside of the class, they can = assume their original=20 access status. 3. As there will be many C++ programs that have been using MI for = aggregation techniques,=20 it would be easier to port these to D if their syntax was to = remain similiar in structure.=20 I myself fit firmly in the the last categor. There is slabs and slabs of = C++ code that I would=20 like to correct the invalid use of Multiple Inheritance to perform = Agregation operations. Criticism/Comments ? =20 =20 ------=_NextPart_001_1220_01C429ED.009F62D0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dwindows-1252"> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY><FONT size=3D2> <DIV>"Patrick Down" <<A=20 href=3D"mailto:Patrick_member pathlink.com">Patrick_member pathlink.com</= A>>=20 wrote in message <A=20 href=3D"news:c6bg2p$146t$1 digitaldaemon.com">news:c6bg2p$146t$1 digitald= aemon.com</A>...</DIV> <DIV> </DIV> <DIV><FONT face=3DArial>Good expansion of the code Patrick, as it = shows how=20 process can flow though the</FONT></DIV> <DIV><FONT face=3DArial>aggregated objects, however, there is one thing = I would=20 like to comment on.</FONT></DIV> <DIV> <DIV><FONT face=3DArial></FONT> </DIV>> ><BR>> >class = Lamp :=20 public Light,<BR>>=20 > &nb= sp; mixin=20 Body cBody,<BR>>=20 > &nb= sp; mixin=20 Switch cSwitch,<BR>>=20 > &nb= sp; mixin=20 Globe cGlobe,<BR>>=20 > &nb= sp; mixin=20 PowerCord cPowerCord<BR>> >{<BR>> >public:<BR>>=20 > Lamp() : Light(), cBody(),=20 cSwitch(cPowerCord,cGlobe), cGlobe(), cPowerCord() {}<BR>> = >}<BR>>=20 ></FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2><FONT face=3DArial>Versus</FONT></DIV> <DIV><BR>> class Lamp : public Light {<BR>> public:<BR>>=20 Lamp() {}<BR>> <BR>> private:<BR>>=20 mixin = Body =20 cBody;<BR>> mixin=20 Switch = cSwitch(cPowerCord,cGlobe);<BR>>=20 mixin Globe = cGlobe;<BR>> mixin PowerCord =20 cPowerCord;<BR>> }</DIV> <DIV> </DIV> <DIV> <DIV><FONT face=3DArial>Originally, I too had the your later syntax, but = changed=20 it the the former for the reasons;</FONT></DIV> <DIV><FONT face=3DArial></FONT> </DIV></DIV> <DIV><FONT face=3DArial>1. Most object diagrams show = aggregated=20 objects as external objects, not internal. For example;</FONT></DIV> <DIV><FONT face=3DArial><IMG alt=3D"External versus Internal Mixin = calls" hspace=3D0=20 src=3D"cid:121a01c42999$2cdc59b0$6501a8c0 stream" align=3Dbaseline=20 border=3D0></FONT></DIV> <DIV><FONT face=3DArial>2. In your example, you have placed = (correctly=20 may I say) the aggreagated objects as private. </FONT></DIV> <DIV><FONT face=3DArial> However, the code = is=20 accessing methods of these objects as though they were public. = </FONT></DIV> <DIV><FONT face=3DArial> By=20 placing </FONT><FONT face=3DArial>the object declarations outside = of the=20 class, they can assume their original </FONT></DIV> <DIV><FONT face=3DArial> access = status.</FONT></DIV> <DIV><FONT face=3DArial></FONT> </DIV> <DIV><FONT face=3DArial>3. As there will be many C++ = programs that=20 have been using MI for aggregation techniques, </FONT></DIV> <DIV><FONT face=3DArial> it would be = easier to port=20 these to D if their syntax was to remain similiar in=20 structure. </FONT></DIV> <DIV><FONT face=3DArial></FONT> </DIV> <DIV><FONT face=3DArial>I myself fit firmly in the the last categor. = There is=20 slabs and slabs of C++ code that I would </FONT></DIV> <DIV><FONT face=3DArial>like to </FONT><FONT face=3DArial>correct the = invalid use of=20 Multiple Inheritance to perform Agregation operations.</FONT></DIV> <DIV><FONT face=3DArial></FONT> </DIV> <DIV><FONT face=3DArial>Criticism/Comments ?</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial></FONT> </DIV> <DIV> </DIV> <DIV> <BR></DIV></FONT></BODY></HTML> ------=_NextPart_001_1220_01C429ED.009F62D0--
Apr 23 2004