Mixin language support (with toy implementation)

[dbarbeau]

Hello TypeScripters.

I might be opening a can of worms which might bring an age of darkness upon us (but see PS). Anyway, I've done an attempt to add language support for mixins.

For the user, it is similar to the extends or implements keywords, and thus goes by mixes. The semantic intent of the keyword is that a Mixture is NOT a derived class of its Mixins, it just copies their static and dynamic properties.

Several mixins can be supplied, the order determines which property will finally be mixed (newer definitions shadow previous definitions).

What this does is roughly equivalent to http://www.typescriptlang.org/Handbook#mixins, except there is no need to copy attributes manually, so mixins become more manageable - hopefully.

class Base {
    say(hello:string) {
        console.log(hello);
    }
}

class Mixin1 {
    something : string = "Couac couac";

    fn1() {
            console.log(this.something);
    }
}


class Mixin2 {      
    something : string = "shadowing you, little duck!";  

    fn2() {
            console.log("The dragon is", this.something);
    }
}

/* Only mixes one mixin */
class SimpleMixture mixes Mixin1 {

}

/* Mixes several mixins, property definitions in newer mixins (from left
to right) shadow those from previous mixins AND those in the mixture
class itself, including inherited ones. */
class MultiMixture extends Base mixes Mixin1, Mixin2 {

}


var sm1 = new SimpleMixture();
sm1.fn1();

var sm2 = new MultiMixture();
sm2.fn1();
sm2.fn2();

console.log( sm1 instanceof Base );
console.log( sm1 instanceof Mixin1 );
console.log( sm2 instanceof Base );
console.log( sm2 instanceof Mixin2 );

Which emits

var __extends = this.__extends || function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();
};
var __applyMixins = this.__applyMixins || function (mixtureTarget) {
    for(var a=1; a<arguments.length; ++a) {
        var mixin = arguments[a];
        Object.getOwnPropertyNames(mixin.prototype).forEach( function(name) {
            mixtureTarget.prototype[name] = mixin.prototype[name];
        })
    }; 
};
var Base = (function () {
    function Base() {
    }
    Base.prototype.say = function (hello) {
        console.log(hello);
    };
    return Base;
})();
var Mixin1 = (function () {
    function Mixin1() {
        this.something = "Couac couac";
    }
    Mixin1.prototype.fn1 = function () {
        console.log(this.something);
    };
    return Mixin1;
})();
var Mixin2 = (function () {
    function Mixin2() {
        this.something = "shadowing you, little duck!";
    }
    Mixin2.prototype.fn2 = function () {
        console.log("The dragon is", this.something);
    };
    return Mixin2;
})();
/* Only mixes one mixin */
var SimpleMixture = (function () {
    function SimpleMixture() {
        Mixin1.apply(this) ;
    }
    __applyMixins(/*mixtureTarget*/ SimpleMixture, Mixin1);
    return SimpleMixture;
})();
/* Mixes several mixins, property definitions in newer mixins (from left
to right) shadow those from previous mixins AND those in the mixture
class itself, including inherited ones. */
var MultiMixture = (function (_super) {
    __extends(MultiMixture, _super);
    function MultiMixture() {
        _super.apply(this, arguments);
        Mixin1.apply(this) ;
        Mixin2.apply(this) ;
    }
    __applyMixins(/*mixtureTarget*/ MultiMixture, Mixin1, Mixin2);
    return MultiMixture;
})(Base);
var sm1 = new SimpleMixture();
sm1.fn1();
var sm2 = new MultiMixture();
sm2.fn1();
sm2.fn2();
console.log(sm1 instanceof Base);
console.log(sm1 instanceof Mixin1);
console.log(sm2 instanceof Base);
console.log(sm2 instanceof Mixin2);

and outputs

>>> Couac couac
>>> shadowing you, little duck!
>>> The dragon is shadowing you, little duck!
>>> false
>>> false
>>> true
>>> false

At this point it seems to work with target ES<6 with quite some limitations (the user can't pass arguments to the mixin constructors). Type checking seems to be working (although I could not make Eclipse or Emacs behave with the new keyword). But be warned Very early experimental preview code from a bad JS programmer who knew nothing about TSC's internals three days ago and who was in a rush. Be warned.

I did this to overcome a maintainability issue with my code and rushed this implementation. It was also an exercise to learn more about TSC. I'm also aware that it might not be a great idea to add keywords to a language each time one gets into trouble, but if others see interest in it or you have suggestions, the branch is here https://github.com/dbarbeau/TypeScript/tree/mixes. Just don't expect this implementation to be stable/complete/anything. Actually, if it can just spark some interest/discussion on how to make mixins more useable, then I'm ok with that.

Daniel
PS: Don't get mad at me :)
PS: I'm now testing this with more "serious code", I will quickly see if it is indeed practical.

[DanielRosenwasser]

Hey @dbarbeau, thanks for the heads up on this interesting work! While we're mainly focusing on ES6 work right now, it's interesting to see this what you've done here. Hopefully we'll get some time to sit down, look at some of the changes and, like you said, get an idea of what might be involved if we wanted something like this.

[whitneyit]

This looks very similar to the conversation around traits in #311

[dbarbeau]

Thanks for the feedback and for pointing out discussion 311. We're going to the same place but they seem to be taking a different way. In both cases there is a new keyword, trait vs mixes (one is a noun, the other a verb). Their proposal is based on a new structure type. My version extends the class declaration. I think my proposal is somewhat more lightweight (and, coming from C++, traits refer to trait classes which are something else) but they do have a lot more background (both academic and with a variety of use cases I didn't even imagine). The comparison is interesting!

[whitneyit]

Yea I agree with the lightweight point. I believe that is the strength and
weakness of mixins over traits. I'll hedge my bets that only one would get
implemented if that.

It's defiantly an interesting topic and in either case I hope that one gets
implemented.

Regards,
James
On 27 Apr 2015 7:19 pm, "dbarbeau" notifications@github.com wrote:

Thanks for the feedback and for pointing out discussion 311. We're going
to the same place but they seem to be taking a different way. In both cases
there is a new keyword, trait vs mixes (one is a noun, the other a verb).
Their proposal is based on a new structure type. My version extends the
class declaration. I think my proposal is somewhat more lightweight (and,
coming from C++, traits refer to trait classes which are something else)
but they do have a lot more background (both academic and with a variety of
use cases I didn't even imagine). The comparison is interesting!

—
Reply to this email directly or view it on GitHub
#2919 (comment)
.

[dbarbeau]

The "design decisions" I made were mostly guided by the urge of having something running quickly - which might not be the best way to design a language.

That's why, after contemplating Python's MRO, I went against it : I wouldn't get it right in such a short term. I then figured that conceptually I didn't need anything more than what is described in the handbook, just automate it. Mixins are just that, mixins, not inheritance, MRO would be overkill. Thus the "newer shadows older declaration" approach to conflict solving (conflict smashing would better suit). I couldn't decide if users should be warned about the smashing or not.

That's also why I chose the "mixes" verb, it'd be easier to grep through TSC how "extends" is implemented if I did something similar.

So a bunch of hacks nothing more. The important for me is to have something running. Whatever gets into TS in the end is not important as long as something gets in there to help us mixers! I can then port my code to whatever is chosen.

Regards,
Daniel

PS: I finally got emacs-tss to behave! As easy as a symlink in the end :)

[danquirk]

Cool stuff. For reference, some other issues related to this concept are #371, #727, #1256

[dbarbeau]

Thanks @danquirk . There is a lot more to mixins than I originally thought!

For example, this proposal doesn't satisfy @RyanCavanaugh's "after-the-fact mixing" requirement (371), which I clearly had no clue about, I tend to overlook the interfacing to existing JS code.

Issue 311 presents attribute renaming to avoid name conflicts, which allows to do fine mixing instead of brutal shadowing. In the case where the mixins come from one project, chances are that they won't shadow themselves unless it's by design. But when mixing mixins from different origins, attribute renaming can come in handy.

Issue 729 seems to more easily satisfy the "after-the-fact mixing", since it is not in the class declaration but as a decorator function. The | operator is confusing to me because it reuses the union type syntax in a slightly different context. But I does resemble the bitwise | operator in some way. It supports attribute renaming. I think the decorator approach could be great if there was a syntax to also put it close the mixture declaration. In new code, one would put the mixins "inline" rather than after the fact

@mymix // a-la Python, more in-context
class Mixture {
}

Where mymix implements whatever mixing logic is needed. But this is already different from 729 in that mymix would be a high-order function taking an original type and returning a new type (which can shadow the original), not an instance (and from there, the | operator would become useless for mixins). Going down that road, there are no mixin classes but high-order decorators (which can mix classes if the user wants to). How all this is implemented and translates to JS is a mystery, specially in the init of the new class.

Concerning 1256's Intersection Types (thankfully, the Bool alphabet is rather small) I'm trying to grasp the concept but haven't yet found a resource which doesn't satellize me immediately, so I can't comment right now on how this proposal is related to 1256. Sorry.

Daniel

[dbarbeau]

In this proposal, concerning my issue with calling mixins' constructors, I think I don't need them. The mixins' default constructors are always called with this (right after any super call). this (the mixture) has all the mixed in attributes available in its own constructor and can give values to them.

Ah, I noticed that private mixed-in attribute remain inaccessible to the mixture. I don't think it's desirable : the mixture's state IS exactly the mixin's state (state==members), no?

[jbondc]

@dbarbeau Nice hacking

You might find this interesting:
https://wiki.php.net/rfc/traits

The Scala example at the bottom was also suggested (with mixin), some interesting history there.

[dbarbeau]

Thanks @jbondc! That is an interesting read, I hope to get some time to dive deeper into it.

Reading all those links leads me to think that, alright my implementation is lightweight and solved an immediate issue for me (with a slight tweak in the mixin precedence : the mixture's implementation should take precedence over mixins' in my very own case, like they do in the PHP link), but really, it is too lightweight to be future proof.

What may be emerging is a Type algebra, some sort of meta-programming (there's already type union, talk about type intersection...). If that metaprogramming could be taken to the level of a hypothetic Typescript-Type-DSL (that may just look like ES/JS/TS, and can be parsed like it but works on types, just avoid C++ template-style metaprog :) ), you could write things like this (just letting the thoughts machine run, not meant to be realistic):

// Takes type arguments and returns a new type.
// Implements the handbook's mixin algo. Could be part of the stdlib.
function mixin<...Mixins> : <> { // this signature tells the compiler that we're using the type DSL.
    // fun with metaprogramming...
    // Return new type;
}

// For after-the-fact mixing, maybe?
// Takes type arguments and returns a new type.
// Implements the handbook's mixin algo. Could be part of the stdlib.
function post_mixin<Mixture, ...Mixins> : <> {
    // fun with metaprogramming...
    // Return new type;
}

// Takes no type arguments and returns a new type
function custom_static_mixin<> : <> {
    // The user chose to create a new type from a predefined set of classes.
    // Copy properties, rename these, modify flags if you wish because you have a DSL for that.
    // Return new type;
}

/*Since mixin returns a type and extends expects a type, this is valid:*/
class MyClass extends mixin<M1,M2,M3>  {
}

/*Same here, name ambiguity can be resolved by taking the function which returns a type*/
class MyOtherClass extends custom_static_mixin {
} 

/* After the fact? */
class A {
}
A = post_mixin<A, M1, M2, M3>; // mixin and overwrite original type.

In this hypothesis functions convey the idea that the user can use a traditional programming metaphor (e.g. imperative) to customize the output type, instead of a declarative way that may need to extend the language syntax and more lexer/parser effort.

Daniel

[dead-claudia]

I do feel that an even better idea would be permitting default interface implementations. Java had this very problem, and fixed it with default interface implementations in Java 8. I feel this could profit from the same addition. (I filed #3536 regarding this alternative)

[nippur72]

Can we replace the verb "mixes" with the word "with" (a la Dart):

class A extends B with M1, M2 { 
}

[dead-claudia]

I agree that the with seems a little clearer and more descriptive of the intent. Also, it's a little easier to reserve, since with isn't a valid identifier already (and won't need new highlighting for a lot of IDEs).

[benliddicott]

Well while we are all at it, here is my take. Anything implemented by a class listed further to the left overrides anything implemented by a class further to the right.

"use strict";
/**
 * Mixins for multiple inheritance. 
 * Usage:
 * class Derived extends BaseOne implements BaseTwo, BaseThree{
 *      baseTwoFunction: (a:number)=>any;
 *      baseThreeProperty: string;
 * 
 *      // Apply any missing base class functions to the derived prototype
 *      private static _mixins = Mixins.Apply(Derived, [BaseTwo, BaseThree]);
 * }
 */
module Mixins {
    export function Apply(derivedClass: any, baseClasses: any[]) {
        var ret: { baseClass: any, functions: { name: string; done: boolean; type: string; }[] }[];
        ret = [];
        baseClasses.forEach(baseClass=> {
            ret.push({ baseClass: baseClass, functions: [] });
            Object.getOwnPropertyNames(baseClass.prototype).forEach(name=> {
                // ONLY if doesn't already exist.
                // Is this a property descriptor on the base class prototype?
                var basePD = Object.getOwnPropertyDescriptor(baseClass.prototype, name);
                var derivedPD = Object.getOwnPropertyDescriptor(derivedClass.prototype, name);
                if (basePD && !derivedPD) {
                    Object.defineProperty(derivedClass.prototype, name, basePD);
                    ret[ret.length - 1].functions.push({
                        name: name, done: true, type: (basePD.get && basePD.set ? "get set" : basePD.get ? "get" : basePD.set ? "set" : basePD.value ? "method" : "")
                    });
                } else {
                    ret[ret.length - 1].functions.push({
                        name: name, done: false, type: (basePD.get && basePD.set ? "get set" : basePD.get ? "get" : basePD.set ? "set" : basePD.value ? "method" : "")
                    });
                }
            });
        });
        return ret;
    }
} 

Further thoughts:

It would be good for mixin-aware mixins to be able to be called in the super() call. I.e. they could provide a method mixin or init or something, to be called as BaseTwo.prototype.init.call(this). These would be called in right-to-left order.

Note also that currently mixins cannot have protected or private members. See #3854 for a proposal on how to fix this.