"Norbert Nemec"  wrote
> Why that? There even is an example in the specs that does just that:
>
> -----------------------
>  Mixins can parameterize symbols using alias parameters:
>         template Foo(alias b)
>         {
>             int abc() { return b; }
>         }
>
>         void test()
>         {
>             int y = 8;
>             mixin Foo!(y);
>             assert(abc() == 8);
>         }
> ------------------------

Yes, but just think how confusing such code would become on a large-scale project ... to my mind this is cruel abuse of the language syntax, and smacks of anti-OO.

The fact that I can drive a car doesn't make it a good scuba companion <g>

Kris wrote:

> "Norbert Nemec"  wrote
>> Why that? There even is an example in the specs that does just that:
>>
>> -----------------------
>>  Mixins can parameterize symbols using alias parameters:
>>         template Foo(alias b)
>>         {
>>             int abc() { return b; }
>>         }
>>
>>         void test()
>>         {
>>             int y = 8;
>>             mixin Foo!(y);
>>             assert(abc() == 8);
>>         }
>> ------------------------
> 
> Yes, but just think how confusing such code would become on a large-scale project ... to my mind this is cruel abuse of the language syntax, and smacks of anti-OO.
> 
> The fact that I can drive a car doesn't make it a good scuba companion <g>

Of course you can write the worst spaghetti code with mixins. They just are an extremely powerful tool that allows you to do much more than you really need. It is up to the programmer to use that tool well.

I don't think access like in the example above is generally a bad thing. It may well be that it really helps you a lot, depending on what you want to do with the mixin.

I think the scary thing about mixins is, that they are not bound to a certain programming concept. "Mixin" may stand for

* a chunk of code to be used in a function
* a mostly independant part of a class, where mixin is similar to
inheritance
* a certain kind of a class member (like a signal, a slot, a property,
whatever
* a complete source file to be used like CPP #include
* a certain aspect of a class

and probably many other things that may not even be invented yet.

Mixins are a very new language concept and nobody knows yet how they should be used well in a library. It will certainly take some time before we have enough experience with mixins to really make use of them and before we can say "This is good programming practice" or "That may lead to problems".

J Anderson wrote:

> Just a though, what if we had some standard mixins in one of the standard libraries.  I mean for thing like vectors you generally write up the same code.  Something like:

If there are standard-library-worthy constructs that need to be implemented this way (or merely where it is obviously the right way) then sure, but it seems backwards to say 'we need some standard mixins'.

That being said, a singleton mixin, and maybe some allocators would be useful.

 -- andy

"Norbert Nemec" wrote
> I think the scary thing about mixins is, that they are not bound to a certain programming concept.

That is the case with D mixins.

> Mixins are a very new language concept and nobody knows yet how they
should
> be used well in a library. It will certainly take some time before we have enough experience with mixins to really make use of them and before we can say "This is good programming practice" or "That may lead to problems".

Mixins are certainly new to D, but have been around for ages elsewhere (Objective-C is a good example, although the concept is narrower). It might be useful for someone with reasonable experience in those other languages to set some guidelines for the uninitiated?

Kris wrote:

> "Norbert Nemec" wrote
>> I think the scary thing about mixins is, that they are not bound to a certain programming concept.
> 
> That is the case with D mixins.
> 
>> Mixins are a very new language concept and nobody knows yet how they
> should
>> be used well in a library. It will certainly take some time before we have enough experience with mixins to really make use of them and before we can say "This is good programming practice" or "That may lead to problems".
> 
> Mixins are certainly new to D, but have been around for ages elsewhere (Objective-C is a good example, although the concept is narrower). It might be useful for someone with reasonable experience in those other languages to set some guidelines for the uninitiated?

I'm talking only about D mixins, these are the only ones I know. As you say, in other languages "mixin" refers to a narrower concept. Maybe, D should have used a new name to make clear that this is something new. They may be used to do what other languages do with their mixins. They may be used for many of the uses where C uses macros. But they may probably also be used for completely new purposes.

If you want to want to transport programming guidelines from Objective-C to D, you will most certainly restrict mixins to a fraction of their real power.

Of course, the standard library should only use mixins for well-known and well-investigated purposes, but whether these match with the concept of Objective-C mixins should probably be left open for the moment.

Please don't get me wrong Norbert: I'm not trying to split hairs or be argumentative.

I suppose I have a similar vague feeling about D mixins that Matthew noted, regarding what he described as their "potential ubiquity". Perhaps that mixin example from the documentation just rubs me the wrong way (with alias and template "mixed-in", just for good measure, it's like a vulgar soup) ... not exactly what one might expect in terms of a "teach by example" approach <g>

I guess that's just me though ...

- Kris


"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c92v2i$1gq$1@digitaldaemon.com...
> Kris wrote:
>
> > "Norbert Nemec" wrote
> >> I think the scary thing about mixins is, that they are not bound to a certain programming concept.
> >
> > That is the case with D mixins.
> >
> >> Mixins are a very new language concept and nobody knows yet how they
> > should
> >> be used well in a library. It will certainly take some time before we have enough experience with mixins to really make use of them and
before
> >> we can say "This is good programming practice" or "That may lead to problems".
> >
> > Mixins are certainly new to D, but have been around for ages elsewhere (Objective-C is a good example, although the concept is narrower). It might be useful for someone with reasonable experience in those other languages to set some guidelines for the uninitiated?
>
> I'm talking only about D mixins, these are the only ones I know. As you
say,
> in other languages "mixin" refers to a narrower concept. Maybe, D should have used a new name to make clear that this is something new. They may be used to do what other languages do with their mixins. They may be used for many of the uses where C uses macros. But they may probably also be used for completely new purposes.
>
> If you want to want to transport programming guidelines from Objective-C
to
> D, you will most certainly restrict mixins to a fraction of their real power.
>
> Of course, the standard library should only use mixins for well-known and well-investigated purposes, but whether these match with the concept of Objective-C mixins should probably be left open for the moment.
>

In article <c92j01$2fq5$1@digitaldaemon.com>, Norbert Nemec says...
>
>Kevin Bealer wrote:
>
>> In article <c90q9p$2t6k$3@digitaldaemon.com>, J Anderson says...
>>>
>>>Just a though, what if we had some standard mixins in one of the standard libraries.  I mean for thing like vectors you generally write up the same code.  Something like:
>>>
>>>template arrayMixin(structName, type, value)
>>>{
>>>     type opIndex(int i) { ... }
>>>...ect...
>>>}
>>>
>>>Then in your own module you could write:
>>>
>>>struct myArray(type)
>>>{
>>>      arrayMixin!(myArray, type, values); //Note that I don't think
>>>values will work ATM.
>>>
>>>      type [] values;
>>>
>>>}
>> 
>> I think this can work, but I think "values" has to be part of the mixin.
>> I
>> don't think a mixin can refer to other stuff "near it" in the class.  The
>> class can see into the mixin, but not the other way.
>
>Why that? There even is an example in the specs that does just that:
>
>-----------------------
> Mixins can parameterize symbols using alias parameters:
>        template Foo(alias b)
>        {
>            int abc() { return b; }
>        }
>
>        void test()
>        {
>            int y = 8;
>            mixin Foo!(y);
>            assert(abc() == 8);
>        }
>------------------------

I don't have a problem with those semantics at all.  I was thinking of something like this:

>-----------------------
> Mixins can parameterize symbols using alias parameters:
>        template Foo(alias b)
>        {
>            // The caller won't mind if I borrow "Z".
>            int abc() { return b + Z; }
>        }
>
>        void test()
>        {
>            int y = 8;
>            int Z = 99;  // The mixin might want one of these.
>            mixin Foo!(y);
>            assert(abc() == 8);
>        }
>------------------------

.. Where anything can bleed in or out of the mixin.

Kevin

i think it would now allow to have the operators finally split up
(comparison and all the like)..

instead you mix in a set of operators for common types, so you don't have to write everyone manually..

should be doable, not?

mixin Addable to get in opAdd, opAddAsign, and such.. mixin Comparable, for opLess, opLEqual, opEqual, opGEqual, opGreater, opGeek..

(but of course, you have to implement then an opComparable wich handles
them..)

"J Anderson" <REMOVEanderson@badmama.com.au> schrieb im Newsbeitrag news:c90q9p$2t6k$3@digitaldaemon.com...
> Just a though, what if we had some standard mixins in one of the standard libraries.  I mean for thing like vectors you generally write up the same code.  Something like:
>
> template arrayMixin(structName, type, value)
> {
>      type opIndex(int i) { ... }
> ...ect...
> }
>
> Then in your own module you could write:
>
> struct myArray(type)
> {
>       arrayMixin!(myArray, type, values); //Note that I don't think
> values will work ATM.
>
>       type [] values;
>
> }
>
> Then you could overload any functions you wish to change.   I'm sure there are heaps of these types of common method groups.
>
> It would be really helpful for lazy programmers like me.
>
> I should add that this is basicly what classes are meant to do but for things like vectors you want a "light-class" which happens to be a struct in D.  I guess there could be a class version as well.
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/

In article <c930sq$4c4$1@digitaldaemon.com>, Kevin Bealer says...
>
>I don't have a problem with those semantics at all.  I was thinking of something like this:
>
>>-----------------------
>> Mixins can parameterize symbols using alias parameters:
>>        template Foo(alias b)
>>        {
>>            // The caller won't mind if I borrow "Z".
>>            int abc() { return b + Z; }
>>        }
>>
>>        void test()
>>        {
>>            int y = 8;
>>            int Z = 99;  // The mixin might want one of these.
>>            mixin Foo!(y);
>>            assert(abc() == 8);
>>        }
>>------------------------
>
>.. Where anything can bleed in or out of the mixin.

This is kind of a special case, as it only works because the mixin is a template and Z is defined at the POI.  Since the template can't stand on its own, it's reasonable to assume that it's designed specifically to be a mixin and carries with it special requirements.  Since this would likely not happen by accident, I'd consider this a feature of mixins rather than a flaw.

Norbert Nemec wrote:

>J Anderson wrote:
>
>  
>
>>Matthew wrote:
>>
>>    
>>
>>>Nothing specific. Just a feeling at the moment.
>>>
>>>Sorry to be vague.
>>> 
>>>
>>>      
>>>
>>I've the same kinda feeling.  It feels like macros with a different
>>syntax.  I mean essentially a mixin is a copy/paste tool.
>>    
>>
>
>So are templates. So what?
>
>D has a powerful compile-time meta-language. The purpose of this
>meta-language is to do all kinds of copy-and-paste operations before the
>real compilation is started.
>
>Unlike the CPP, this source-code processing cannot by fully split out of the
>compiling process. Unlike CPP, it uses the same namespace as the compiler,
>but it offers most of the power of the CPP.
>
>C++ had two steps of "preprocessing": first the CPP, then the template
>instatiation (which is basically lots of copy-and-paste as well) then the
>real compilation.
>
>Mixins basically *are* macros with a different syntax. But through that
>syntax, they are far better integrated into the language itself then
>CPP-macros ever were.
>  
>
Sure but I've a feeling that they may lead to some places where we don't want to go.  I'm not quite sure where yet.


-- 
-Anderson: http://badmama.com.au/~anderson/