www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Implement a class with mixins

reply Frank Benoit <keinfarbton nospam.xyz> writes:
Does a protected inheritance make sense in a language without multiple
inheritance? Inherit private is for a "implemented with" relation. And
this is perhaps better made with the mixin feature.

But to use mixins like base classes for implementation, mixins are
missing a Ctor ( and DTor ) integration. It should be possible for a
mixin to have a Ctor which is automatically called while the object is
contructed. Or it can be called manually ( with args ) from the class ctor.

.template Foo(){
.  this( int a ){}
.}
.
.template Bar(){
.  this(){}
.}
.
.class C{
.  mixin Foo foo;
.  public this(){
.    foo.this( 2 ); // if missing => compile error
.    // bar.this() is implicit called, manually call is possible
.  }
.}
May 06 2006
next sibling parent Frank Benoit <keinfarbton nospam.xyz> writes:
I missed the Bar mixin in the previous posting.

 .class C{
 .  mixin Foo foo;

 .  public this(){
 .    foo.this( 2 ); // if missing => compile error
 .    // bar.this() is implicit called, manually call is possible
 .  }
 .}

May 06 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Frank Benoit wrote:
 Does a protected inheritance make sense in a language without multiple
 inheritance? Inherit private is for a "implemented with" relation. And
 this is perhaps better made with the mixin feature.
 
 But to use mixins like base classes for implementation, mixins are
 missing a Ctor ( and DTor ) integration. It should be possible for a
 mixin to have a Ctor which is automatically called while the object is
 contructed. Or it can be called manually ( with args ) from the class ctor.

It would be great if there were an easy way to make this work. As it is, I have to know in advance something is intended to be a mixin and create separate methods for this. For a somewhat more complicated example, I use the technique here: http://www.home.f4.ca/sean/d/stream.d Sean
May 07 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Sean Kelly wrote:
 Frank Benoit wrote:
 Does a protected inheritance make sense in a language without multiple
 inheritance? Inherit private is for a "implemented with" relation. And
 this is perhaps better made with the mixin feature.

 But to use mixins like base classes for implementation, mixins are
 missing a Ctor ( and DTor ) integration. It should be possible for a
 mixin to have a Ctor which is automatically called while the object is
 contructed. Or it can be called manually ( with args ) from the class 
 ctor.

It would be great if there were an easy way to make this work. As it is, I have to know in advance something is intended to be a mixin and create separate methods for this. For a somewhat more complicated example, I use the technique here: http://www.home.f4.ca/sean/d/stream.d

In every case I've seen or dreamt up so far, a template is either intended to be a mixin, or not. Is that your experience too? I suspect that 'mixin' should be specified in the template declaration, rather than just the instantiation.
May 08 2006
parent reply Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
 
 In every case I've seen or dreamt up so far, a template is either 
 intended to be a mixin, or not. Is that your experience too?

Yes.
 I suspect that 'mixin' should be specified in the template declaration, 
 rather than just the instantiation.

Perhaps it should, though I'm hesitant to suggest a special declaration syntax unless it offers something over the current approach. Sean
May 08 2006
next sibling parent pragma <pragma_member pathlink.com> writes:
In article <e3nr1u$1ekk$1 digitaldaemon.com>, Sean Kelly says...
Don Clugston wrote:
 
 In every case I've seen or dreamt up so far, a template is either 
 intended to be a mixin, or not. Is that your experience too?

Yes.
 I suspect that 'mixin' should be specified in the template declaration, 
 rather than just the instantiation.

Perhaps it should, though I'm hesitant to suggest a special declaration syntax unless it offers something over the current approach.

Personally, I just use the 'M' suffix convention (in place of 'T') to avoid confusing myself with what's a type template and what is a mixin. But I do agree with the point made, that it would be nice to restrict the usage of templates according to their intended purpose. Offhand, I can't think of a single type template that would be useful in the same context as your typical mixin (or vice-versa). However, I'm hesitant to agree that using 'mixin' in the declaration is the answer - do we still require the 'auto' modifier for auto class declarations? - EricAnderton at yahoo
May 08 2006
prev sibling next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Tue, 09 May 2006 02:19:07 +1000, Sean Kelly <sean f4.ca> wrote:

 Don Clugston wrote:
  In every case I've seen or dreamt up so far, a template is either  
 intended to be a mixin, or not. Is that your experience too?

Yes.

Yes.
 I suspect that 'mixin' should be specified in the template declaration,  
 rather than just the instantiation.

Perhaps it should, though I'm hesitant to suggest a special declaration syntax unless it offers something over the current approach.

Communication. It would tell code readers/maintainers the intention of the author. It reduces guess work on their part, and this leads to cheaper maintenance costs (less mistakes, less reading time, etc). -- Derek Parnell Melbourne, Australia
May 08 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Sean Kelly wrote:
 Don Clugston wrote:
 In every case I've seen or dreamt up so far, a template is either 
 intended to be a mixin, or not. Is that your experience too?

Yes.
 I suspect that 'mixin' should be specified in the template 
 declaration, rather than just the instantiation.

Perhaps it should, though I'm hesitant to suggest a special declaration syntax unless it offers something over the current approach.

Me too, but I feel that mixins ought to be much more useful than they currently are. They don't feel very disciplined. I can see two kinds of mixins: (a) 'in' mixins, which are just like normal templates, except that they can use variables/functions/etc from the instantiation scope. Their name is the only thing that needs to appear in the instantiation scope. (b) 'out' mixins, which can dump arbitrary declarations into the instantation scope. The second type are far more scary, and so far I've found them less useful. You'd always want a 'mixin' keyword in front of any instantiation of them, because they could easily obfuscate code. But I wonder if we really need it for the 'in' mixins. I'm finding cases where I write: int bar; // mixin 'foo' creates a local function that requires a local integer called 'bar'. mixin foo!(int) baz; baz(45); when actually I'd like to write int bar; foo!(int)(45); I'm just bouncing around ideas, don't take it too seriously.
May 09 2006