mixin classes and interfaces are complementary.

mixin classes don't provide polymorphing so they don't do what an interface do. Interfaces don't provide code reuse so they don't do what mixin classes do.

Both are necessary to do what C++ does with multiple inheritances.

You're mixin' the concepts (pun intended). The nice thing about mixin classes and interfaces, is that one provides the implementation and the other provides the interface. It's two separate things.

Your suggestion would make it pretty much the same thing as C++, but you would be back to having to implement multiple inheritance which is what I want to avoid with the use of mixin classes. I'm definitely not against C++' way of doing things, it is after all my preferred programming language, but I'm also not trying to implement C++ as script language so I do not plan to follow it in all matters as I believe there are other ways that can be just as effective yet easier to use (and implement for me).

Anyway, you can accomplish pretty much the same thing with mixins and interfaces the way I want it to work:


interface IObject
{
void Foo();
}
mixin class Mixin : Object
{
void Bar() {}
}
class Object1 : Mixin
{
// Foo() is required, because the inclusion of the Mixin also includes the IObject interface
void Foo()
{
// The Bar() function implementation is provided by the Mixin class
Bar();
}
}

// Casting to the interface is allowed, but not to the mixin class
Object1 o1();
IObject @o = cast<IObject>(o1);


I thank you for the feedback, but unfortunately I'll have to inform you that this suggestion is not going to be implemented.

Regardless, newbie scripters should preferrably not have to know the details of how classes, mixins, and interfaces work. They should just be given a preimplemented model and then work on that. Standard classes, mixins, and interfaces should be implemented by the application developer and provided as a library for the scripter to use. If the scripter has to write scripts that require lots of classes, interfaces, and mixins then the scripter also has to have more advanced programming skills, which I should believe make him or her very capable of understanding the concept of each.

mixin classes and interfaces are complementary.

mixin classes don't provide polymorphing so they don't do what an interface do. Interfaces don't provide code reuse so they don't do what mixin classes do.

Given that one doesn't usually talk about 'interface classes', I'm a little perturbed at the moniker (and the keyword) 'mixin class'.

They aren't classes in any meaningful sense of the term (i.e. you can't instantiate them, you can't cast them, and they don't confer polymorphism), so why call them classes?

Also, given that they don't confer polymorphism, and that multiple mixins can overlap, they don't really fit the concept of inheritance. Why use inheritance syntax to use mixins, as opposed to some sort of inline syntax (a la D, I guess).

I decided to use 'mixin class' because I was also thinking about adding 'mixin functions' in the future, and wanted to keep the two separate.

I understand your arguments against calling it 'mixin classes'. I first learned about mixins from the D language, but I didn't quite like the syntax they chose to use. I felt it would be cleaner to build upon the syntax of inheritance as it is similar. D's mixins are more generic as far as I understand it. Their mixins can represent a simple variable declaration, a function, class, or just an expression.

I didn't want to go as far as the D language to make a fully generic mixin feature in AngelScript. My main goal with the mixin classes is to allow better code reuse, without having to implement multiple inheritance.

My main goal with the mixin classes is to allow better code reuse, without having to implement multiple inheritance.

<somewhat offtopic>
The idea that multiple inheritance results in better code reuse is ringing all my alarm bells. In my experience the most it accomplishes is to turn code reuse into an unattainable nightmare...

Mixins are a better way to go, certainly. Although they have a lot of functional overlap with plain-old object composition. Not clear that mixins always increase the reusability of code (mixins tend to be quite closely tied to the types that implement them).
</somewhat offtopic>

I agree with you. I rarely use multiple inheritance myself, but there are some cases where it works well.

I'll have to admit that I don't have experience with using mixins as none of the programming languages that I use on a daily basis support them. However, I truly believe that the way I'm implementing them for AngelScript will add a lot to the language for those who wanted to use multiple inheritance, e.g. to provide default implementations for entity controllers. At the same time they won't cause any negative impact to those who'd rather not use them at all.

I've completed the implementation of mixin classes in revision 1408.

Version 2.25.0 of the library should be released in a week or two, in the meantime it would be great if those who are interested in this feature can give the WIP a go.

Regards,
Andreas