Mixins Paper

Modular Object-Oriented Programming with Units and Mixins explains why mixins are so important. Why aren't more people turned on to this stuff?

The Point of JDNC, XAML, and XUL

My colleague assumed that the point was to enable round-tripping gui builders. He didn't even think that web deployment was a significant goal.

Now that he mentions, I can't see that html/xml confers any technical benefit for running in the browser. What about round-trip editting? Is round tripping gui building really so much easier with an xml dialect than with code which uses simplified widget api?

Better AOP

Here's a better way to support Aspect Oriented Programming:

• mixins!
• wildcard methods
• methods that override constructors (and superclasses) for a class

This is approach is nice because it doesn't introduce an entirely new abstraction for extending code. With mixins, the caller can extend a class that the mixin author didn't know about. With wildcard methods, the mixin can be more flexible.

Overriding constructors is probably the most controversial part, by which I mean lanugage support for the pattern of my July 1 entry. For example, many component libraries consist of several classes, but for ease-of-use, only make a few of those classes available. In order to extend the behavior of the implementation classes, it would be nice to be able to do something like:

public class A2 extends A {

    B.new() {

        return new B2();

    }

}

Nature of Aspect Oriented Programming

If you've been frustrated about exactly what AOP is, you'll enjoy Aspect-Oriented Programming is Quantification and Obliviousness. Also interesting is the realization that Aspect-Oriented Programming is just "intercessional reflection"

More on Objected Oriented Design

In order for a class to be extensible, it must never obtain references to objects directly.

It must use separate factory methods whose sole responsibility is to obtain and return those references. That way, a subclass can easily override those methods to substitute different objects.

For example, instead of:

public class Fu {

    public void doSomethingWithBar() {

        new Bar().doSomething();

    }

}

use the following:

public class Fu {

    public void doSomethingWithABar() {

        newBar().doSomething();

    }



    protected Bar newBar() {

        return new Bar();

    }

}

which allows:

public class Fu2 extends Fu {

    protected Bar newBar() {

        return new Bar2();

    }

}

A Solution to the Fragile Base Class Problem explains (peripherally) why these methods should be protected.

This is the GOF factory pattern, but it should be applied more generally. Possibly people restrict its use because they're worried about components not being sufficiently well thought out. There may be some subtle dependency on the actual object implementations. To specify that there isn't any such dependency, it would be be better to use an interface for the return type of these factory methods:

protected BarInterface newBar() {

    return new BarImplementation();

}