Unclear on mixin restrictions, and an example

May 02, 2004
Posted by Mike Swieton
Permalink
Mike Swieton
Permalink
I've been following the discussion on aggregation and mixins and I've been running into a few questions here.

Firstly, it is not clear to me what the difference between aggregation and mixins.

Also, I am not really able to see what the meaning of mixing in a class is. Public inheritance, of course, means "is an X", and implementing an interface is often described as "can do X". Would a mixin mean something like "does X like this"? This topic is only tangentially related, of course, but I think it's important to consider. Knowing what you mean when you program something is an important part of 'programming on purpose' (to steal the name from an excellent book).

Also, Matthew's proposal has some the odd restriction that mixins define no fields: Firstly, is this public or all fields? And what is the reasoning for this? I really don't understand why.

I'd like to throw out there an example where I think mixins would be tremendously useful. This use would not be allowed under Matthew's proposal, and I think that's a shame if there's not very strong reasons.

Two particular needs come up for me that I'd use a mixin for: logging, and the gang of four's Observer pattern. I'll look at the latter here. Below is an idea for the use of mixins for it:

Please forgive any syntax errors; I work on C++ and Java by day and make the world safe for D users by night...

class Observable(EventType)
// note this is a regular class, which is important to allow mixins to be
// subclassed. In this instance, I might subclass with a class that used
// mutexes to allow multithreaded operation. The ability to be templated
like // a regular class is extremely powerful, especially in mixins. {
	public:
		void addListener(Observer!(EventType) listener) { ... }
		void rmListener(Observer!(EventType) listener) { ... }
		void notify(EventType e) { ... }

		// would this use of Observer be forbidden under Matthew's proposal?
		void stealListeners(Observable!(EventType) speaker) { ... }
	private:
		// Matthew's proposal forbids this, doesn't it?
		list!(Observer!(EventType)) observers;
}

interface Observer(EventType)
{
	public:
		void onEvent(EventType);
}

class MyDialog :
	MyGUIComponentSuperclass,
	mixin Observable!(UserEvent),
	// multiple mixinizing is ok, different signatures. I think we forbid
	// multiple mixing of identical mixins. How do fields affect this, though?
	// This example is OK, because they are of different type (templated), but
	// what if it were, say, an int?
	mixin Observable!(ButtonEvent),
	mixin Observable!(WindowEvent)
{
	public:
		...
		void close() { notify(new WindowEvent(...)); }
}

It appears to me that the above simple example would be impossible under the existing proposal. I'd like to argue that, from the using programmer's perspective, these few abilities could be extremely useful.

Any thoughts on this?

Mike Swieton
__
The world is my domain.
	- Carlos the Jackal
Forums
