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
.  }
.}

I missed the Bar mixin in the previous posting.

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

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

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.

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

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

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

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.