gistfile1.js

function mixin(from, to) {
    var property;
    for (property in from) {
        if (!to.hasOwnProperty(property)) {
            to[property] = from[property];            
        }
    }
    return to;
}

If you're going to override the properties anyway, you might want to just do:

function mixin(from, to) {
    var property;
    for (property in to) {
        from[property] = to[property];            
    }
    return from;
}

Maybe we could update the names to this:

function mixin(drink, mix) {
    var property;
    for (property in mix) {
        drink[property] = mix[property];  // shake
    }
    return drink;
}

I think YUI just clobbers them, but my Java conscience still wants to be able to override methods. :)

I figured that was the case.

The apply function might be a better option altogether: https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Objects/Function/Apply

I don't understand how this helps the mixin? Are you talking about calling the mixin method via apply like this:

function mixin(from) {
    var property;
    for (property in from) {
        if (!this.hasOwnProperty(property)) {
            this[property] = from[property];            
        }
    }
}

mixin.call(myInstance, superInstance);

(using https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Objects/Function/Call instead of apply so I don't have to wrap arg in [])

Wow, so I tried the idea out:

http://s.dangertree.net/p/constr_perf5.png

This is all relating back to http://rhyolight.posterous.com/javascript-constructor-performance (in case anyone reading was wondering)

Re: apply

You're right, it's more appropriate for the classic prototypal inhertance.

Re: performance. Woohoo, good deal! (Though I'm glad you simplified things a bit for the blog follow-up. I started getting lost in all those permutations.)