Here I thought mixins were a pain but I've been going through mintl and
experimenting with consolidating shared code into mixins and they've been
working great. I'd like to really say thanks to Walter for adding mixins. I
wasn't convinced before but I'm really liking them now. In my sandbox mintl
now has three mixins:
- one for opCat-like functions (6 functions)
- one for opApply overloads and variations (8 functions)
- one for backwards opApply and toSeq variations (5 functions)

They cut way down on the cut-and-paste aspect of mintl that had been bothering me. It's to the point where there isn't any "boilerplate" code in the individual containers.

I've found using public mixins to be more successful that using private mixins. Private symbols seem to trip up mixins. The rules are probably obvious but I haven't taken the time to figure them out so I've gotten in the habit of only mixing in public declarations and having the mixins only reference public symbols.

-Ben

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:chr4dn$u29$1@digitaldaemon.com...
> Here I thought mixins were a pain but I've been going through mintl and experimenting with consolidating shared code into mixins and they've been working great. I'd like to really say thanks to Walter for adding mixins.
I
> wasn't convinced before but I'm really liking them now. In my sandbox
mintl
> now has three mixins:
> - one for opCat-like functions (6 functions)
> - one for opApply overloads and variations (8 functions)
> - one for backwards opApply and toSeq variations (5 functions)
>
> They cut way down on the cut-and-paste aspect of mintl that had been bothering me. It's to the point where there isn't any "boilerplate" code
in
> the individual containers.

Template mixins were a bit of a shot in the dark. They don't exist in other languages, so although I was pretty sure they were useful, it's good to see they are panning out.


> I've found using public mixins to be more successful that using private mixins. Private symbols seem to trip up mixins. The rules are probably obvious but I haven't taken the time to figure them out so I've gotten in the habit of only mixing in public declarations and having the mixins only reference public symbols.

I'd like to see some small examples of the tripups. There might be a stupid mistake in the parser (not that that has ever happened before <g>).

In article <chr4dn$u29$1@digitaldaemon.com>, Ben Hinkle says...
>
>Here I thought mixins were a pain but I've been going through mintl and experimenting with consolidating shared code into mixins and they've been working great. I'd like to really say thanks to Walter for adding mixins.

Agreed.  I've found them to be tremendously useful in avoiding duplicate code and suspect they'll come in handy for other purposes as well.

>I've found using public mixins to be more successful that using private mixins. Private symbols seem to trip up mixins. The rules are probably obvious but I haven't taken the time to figure them out so I've gotten in the habit of only mixing in public declarations and having the mixins only reference public symbols.

I personally haven't had problems with either, though I've tended to use alias parameters if I want mixins to access hidden members.


Sean

On Thu, 9 Sep 2004 20:10:57 -0700, Walter <newshound@digitalmars.com> wrote:

<snip>

>> I've found using public mixins to be more successful that using private
>> mixins. Private symbols seem to trip up mixins. The rules are probably
>> obvious but I haven't taken the time to figure them out so I've gotten in
>> the habit of only mixing in public declarations and having the mixins only
>> reference public symbols.
>
> I'd like to see some small examples of the tripups. There might be a stupid mistake in the parser (not that that has ever happened before <g>).

I'm not sure whether this is what Ben has encountered but if you say this...

--[mixin2.d]--
import mixin2_def.d;

void main()
{
  B b = new B();
  b.foo();
}

--[mixin2_def.d]--
module mixin2_def.d;

template A()
{
public:
  int public_value;

private:
  int private_value;
}

class B {
  mixin A;

  void foo()
  {
    public_value = 3;
    private_value = 4;
  }
}

Then you get...

D:\D\src\temp>dmd mixin2.d mixin2_def.d
mixin2_def.d(12): class B A!().private_value is private

It could be that this is the intended behaviour, it just seemed weird to me at first (I expected the private to be mixed into the class) and now that Ben mentions something like it bothering him I thought it was a good idea to bring it up again.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

I agree with all you say here, and i have found them usefull too, but shouldn't we have a way to mixin construcors?

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:chr4dn$u29$1@digitaldaemon.com...
> Here I thought mixins were a pain but I've been going through mintl and experimenting with consolidating shared code into mixins and they've been working great. I'd like to really say thanks to Walter for adding mixins.
I
> wasn't convinced before but I'm really liking them now. In my sandbox
mintl
> now has three mixins:
> - one for opCat-like functions (6 functions)
> - one for opApply overloads and variations (8 functions)
> - one for backwards opApply and toSeq variations (5 functions)
>
> They cut way down on the cut-and-paste aspect of mintl that had been bothering me. It's to the point where there isn't any "boilerplate" code
in
> the individual containers.
>
> I've found using public mixins to be more successful that using private mixins. Private symbols seem to trip up mixins. The rules are probably obvious but I haven't taken the time to figure them out so I've gotten in the habit of only mixing in public declarations and having the mixins only reference public symbols.
>
> -Ben

In article <chr6fc$uos$1@digitaldaemon.com>, Walter says...
>
>
>"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:chr4dn$u29$1@digitaldaemon.com...
>> Here I thought mixins were a pain but I've been going through mintl and experimenting with consolidating shared code into mixins and they've been working great. I'd like to really say thanks to Walter for adding mixins.
>I
>> wasn't convinced before but I'm really liking them now. In my sandbox
>mintl
>> now has three mixins:
>> - one for opCat-like functions (6 functions)
>> - one for opApply overloads and variations (8 functions)
>> - one for backwards opApply and toSeq variations (5 functions)
>>
>> They cut way down on the cut-and-paste aspect of mintl that had been bothering me. It's to the point where there isn't any "boilerplate" code
>in
>> the individual containers.
>
>Template mixins were a bit of a shot in the dark. They don't exist in other languages, so although I was pretty sure they were useful, it's good to see they are panning out.
>
>
>> I've found using public mixins to be more successful that using private mixins. Private symbols seem to trip up mixins. The rules are probably obvious but I haven't taken the time to figure them out so I've gotten in the habit of only mixing in public declarations and having the mixins only reference public symbols.
>
>I'd like to see some small examples of the tripups. There might be a stupid mistake in the parser (not that that has ever happened before <g>).
>
>
I too like (and use) mixin a lot.
Thanks for your "shot in the dark".

Marcello

Regan Heath wrote:

> On Thu, 9 Sep 2004 20:10:57 -0700, Walter <newshound@digitalmars.com> wrote:
> 
> <snip>
> 
>>> I've found using public mixins to be more successful that using private
>>> mixins. Private symbols seem to trip up mixins. The rules are probably
>>> obvious but I haven't taken the time to figure them out so I've gotten
>>> in
>>> the habit of only mixing in public declarations and having the mixins
>>> only
>>> reference public symbols.
>>
>> I'd like to see some small examples of the tripups. There might be a stupid mistake in the parser (not that that has ever happened before <g>).
> 
> I'm not sure whether this is what Ben has encountered but if you say this...
> 
> --[mixin2.d]--
> import mixin2_def.d;
> 
> void main()
> {
>    B b = new B();
>    b.foo();
> }
> 
> --[mixin2_def.d]--
> module mixin2_def.d;
> 
> template A()
> {
> public:
>    int public_value;
> 
> private:
>    int private_value;
> }
> 
> class B {
>    mixin A;
> 
>    void foo()
>    {
>      public_value = 3;
>      private_value = 4;
>    }
> }
> 
> Then you get...
> 
> D:\D\src\temp>dmd mixin2.d mixin2_def.d
> mixin2_def.d(12): class B A!().private_value is private
> 
> It could be that this is the intended behaviour, it just seemed weird to me at first (I expected the private to be mixed into the class) and now that Ben mentions something like it bothering him I thought it was a good idea to bring it up again.
> 
> Regan
> 

yep, that looks familiar. One would think "private" meant the usual D notion of private: "public in the module".

Ok, I understand.

In C++ the -> operator is overloaded for iterators in order to access nodes in a container.  How does D do this?  Would it be useful to have something similar to a mixin that was a pointer?

(I'm not a D programmer so forgive me if my syntax is off.)
Something like:

template ListNode(T)
{
  mixin T;
  ListNode *next, *previos;
}

template ListIterator(T)
{
  mixin ListNode(T) *node;
}

In article <ci4plq$302s$1@digitaldaemon.com>, Craig Black says...
>
>In C++ the -> operator is overloaded for iterators in order to access nodes in a container.  How does D do this?  Would it be useful to have something similar to a mixin that was a pointer?
>
>(I'm not a D programmer so forgive me if my syntax is off.)
>Something like:
>
>template ListNode(T)
>{
>  mixin T;
>  ListNode *next, *previos;
>}
>
>template ListIterator(T)
>{
>  mixin ListNode(T) *node;
>}
>

I'm not sure how exactly you plan on approaching a linked list using D templates, but here's just one example of how to proceed:

# // (assuming you want templated classes)
#
# class Listnode(T){
#     T value; // no mixin needed here
#     Listnode!(T) next, previous;
# }
#
# class ListIterator(T){
#     mixin Listnode!(T);
# }

In the above example, there's almost no difference between a mixin and a template instance in the ListIterator class. Mixins really show their value when you start throwing in additional methods that can be coalesed into a general behavior... this technique is great for Aspect-Oriented design.

- Pragma
[[ Eric Anderton at yahoo dot com ]]