"Y.Tomino" <demoonlit@inter7.jp> skrev i en meddelelse news:brj1ui$r60$1@digitaldaemon.com...
> (I'm glad! :-)
>
> I suggest "interface delegation" like Delphi.
...
>     property A: TheClassImplementsInterfaceA read ARef implements

This is a nice concept.
I do not think it entirely replaces the concept of mixins but it certainly
does solve a number of issues. There are also performance issues - mixins
are not only useful for late binding interface implementation. Also mixins
decouples "who implements what" from the interface. In any case this is a
nice idea. If the delegate concept is implemented, one might argue that
mixins will not add enough benefits to warrant the added complexity of the
language ... but then again it could be useful in its own right :-)

BTW, Ruby also has a concept of delegates - but this is implemented on top of the language thanks to reflection and the highly dynamic nature of this language. As far as I am aware delegates are not used nearly as often as mixins in Ruby, but then again Ruby doesn't really have the same concept (or need for) of interfaces.

One example of mixins in Ruby: An array module is mixed into a number of
classes offering collections. Another mixin could then be created to
piggy-backs on array methods by supplying a sort method working on the
standard array methods. Note that there isn't really an array interface,
just a convention of what methods an array has. (This is known as Duck
typing: If it quacks like a duck, it is a duck.). This is a way to use
mixins without using interfaces.
Contrary to Ruby, D is statically typed. This means the compiler would
discover errors Ruby would only discover in runtime. Yet mixins adds a
rather informal dynamic nature to class design while avoiding some of the
potential runtime errors seen in Ruby.
There are links from here to the concepts of algorithms in C++ STL. You can
have algorithms mixed in. Mixins could probably be templated as well.

class DiskRecordSet { T get(int index) { ... }; void set(T value) { ... };
int size() { ...} }
class MemArray { T get(int index) { ... }; void set(T value) { ... }; int
size() { ...} }
class QuickSorter { void sort() { ... impl. quick sort using get, set, size
methods } }
class MergeSorter { void sort() { ... impl. merge sort using get, set, size
methods } }

class Filer : mixin DiskRecordSet, mixin MergeSorter {} class WorkingSet : mixin MemArray, mixin MergeSorter {}

These operations do not work in interfaces but rather on conventions. This
makes it easy to create efficient implementations with relying heavily on
specific class types which would require templates that is often more
tedious to work with.
At the same time mixins are so much convention that it is useful to combine
them with interfaces at the inter-module level. Thus we could combine the
above storage implementations with stream interfaces as shown earlier.

> Another advantage is that "interface delegation" don't require special
> definition
> like "mixin MReader { char [] Read() { ... } }".
> "Interface delegation" is able to use the existing class.

Hmm not necessarily. The mixin definition was just a suggestion. My proposal also considers the alternative of allowing ordinary classes to be mixed in:

class Reader { char [] Read() {...} }
class Storage : mixin Reader { .... }


Mikkel

The only possible problem that crosses my mind is that mixins will need some mechanism to access the data members of the classes that import them. There will also need to be a safety mechanism to keep mixins from modifying class data that they shouldn't be touching.

It's late at night, though, and I can't think of any example syntax that illustrates what I'm talking about.

--Benji

You should write a book!

12-months of brain freeze. ;(


"Benji Smith" <dlanguage@xxagg.com> wrote in message news:brm8ue$2mb0$1@digitaldaemon.com...
> The only possible problem that crosses my mind is that mixins will need
some
> mechanism to access the data members of the classes that import them.
There will
> also need to be a safety mechanism to keep mixins from modifying class
data that
> they shouldn't be touching.
>
> It's late at night, though, and I can't think of any example syntax that illustrates what I'm talking about.
>
> --Benji
>
>

On Tue, 16 Dec 2003 17:47:03 +1100, "Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote:

>You should write a book!
>
>12-months of brain freeze. ;(

Ouch.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9451B74F0618Epatcodemooncom@63.105.9.61...
> There is going to be (hopefully, please, please)
> another pass at the template implementation in D

Yes. <g>