www.digitalmars.com         C & C++   DMDScript  

D - Mixin ?

reply "fred" <info fleet-manage.com> writes:
Is Mixins planned for the version 1.0 release ?
Apr 19 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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
parent reply "fred" <info fleet-manage.com> writes:
"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
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
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
prev sibling parent John Reimer <jjreimer telus.net> writes:
Ilya Minkov wrote:

 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

Ha ha! That was actually kind of funny, eye. :-D
Apr 20 2004
prev sibling parent reply "Warren" <warrens seanet.com> writes:
Content-Type: text/plain;
	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
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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): 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
parent "fred" <info fleet-manage.com> writes:
 "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): D/9093 I get the impression it's something of a replacement for multiple inheritance (since D doesn't have MI).

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.
Apr 20 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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
parent reply "fred" <info fleet-manage.com> writes:
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
parent reply Patrick Down <Patrick_member pathlink.com> writes:
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
parent "fred" <info fleet-manage.com> writes:
Content-Type: multipart/alternative;
	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.

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" &lt;<A=20 href=3D"mailto:Patrick_member pathlink.com">Patrick_member pathlink.com</= A>&gt;=20 wrote in message <A=20 href=3D"news:c6bg2p$146t$1 digitaldaemon.com">news:c6bg2p$146t$1 digitald= aemon.com</A>...</DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=3DArial>Good expansion of the&nbsp; 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>&nbsp;</DIV>&gt; &gt;<BR>&gt; &gt;class = Lamp :=20 public Light,<BR>&gt;=20 &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;mixin=20 Body&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cBody,<BR>&gt;=20 &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;mixin=20 Switch&nbsp;&nbsp;&nbsp;&nbsp;cSwitch,<BR>&gt;=20 &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;mixin=20 Globe&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cGlobe,<BR>&gt;=20 &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;mixin=20 PowerCord cPowerCord<BR>&gt; &gt;{<BR>&gt; &gt;public:<BR>&gt;=20 &gt;&nbsp;&nbsp;&nbsp; Lamp() :&nbsp; Light(), cBody(),=20 cSwitch(cPowerCord,cGlobe), cGlobe(), cPowerCord() {}<BR>&gt; = &gt;}<BR>&gt;=20 &gt;</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2><FONT face=3DArial>Versus</FONT></DIV> <DIV><BR>&gt; class Lamp : public Light {<BR>&gt; public:<BR>&gt;=20 &nbsp;&nbsp;&nbsp; Lamp()&nbsp; {}<BR>&gt; <BR>&gt; private:<BR>&gt;=20 &nbsp;&nbsp;&nbsp; mixin = Body&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 cBody;<BR>&gt; &nbsp;&nbsp;&nbsp; mixin=20 Switch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = cSwitch(cPowerCord,cGlobe);<BR>&gt;=20 &nbsp;&nbsp;&nbsp; mixin Globe&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = cGlobe;<BR>&gt; &nbsp;&nbsp;&nbsp; mixin PowerCord&nbsp;&nbsp;&nbsp;=20 cPowerCord;<BR>&gt; }</DIV> <DIV>&nbsp;</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>&nbsp;</DIV></DIV> <DIV><FONT face=3DArial>1.&nbsp;&nbsp; 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.&nbsp;&nbsp; In your example, you have placed = (correctly=20 may I say) the aggreagated objects as private. </FONT></DIV> <DIV><FONT face=3DArial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; However, the code = is=20 accessing methods of these objects as though they were public. = </FONT></DIV> <DIV><FONT face=3DArial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; By=20 placing&nbsp;</FONT><FONT face=3DArial>the object declarations outside = of the=20 class, they can assume their original </FONT></DIV> <DIV><FONT face=3DArial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; access = status.</FONT></DIV> <DIV><FONT face=3DArial></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial>3.&nbsp;&nbsp; As there will be many C++ = programs that=20 have been using MI for aggregation techniques, </FONT></DIV> <DIV><FONT face=3DArial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; it would be = easier to port=20 these to D if their syntax was to remain similiar in=20 structure.&nbsp;</FONT></DIV> <DIV><FONT face=3DArial></FONT>&nbsp;</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&nbsp;Inheritance to perform Agregation operations.</FONT></DIV> <DIV><FONT face=3DArial></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial>Criticism/Comments ?</FONT></DIV> <DIV>&nbsp;&nbsp;&nbsp;&nbsp; </DIV> <DIV><FONT face=3DArial></FONT>&nbsp;</DIV> <DIV>&nbsp;</DIV> <DIV>&nbsp;<BR></DIV></FONT></BODY></HTML> ------=_NextPart_001_1220_01C429ED.009F62D0--
Apr 23 2004