• Matthias Spycher (52/52) Jan 03 2004 charset="iso-8859-1"

"Matthias Spycher" <matthias coware.com> writes:

	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The D spec says that interface member functions do not have =
implementations.

http://www.digitalmars.com/d/class.html#interface

What do you think of the following extension?

A member function can be defined (implemented) inside an interface as =
long as it accesses object state through methods declared in the same =
interface or an inherited interface. Use of this to access the current =
object is also allowed. Example:

interface TreeNode {

    TreeNode parent();
    TreeNode next();  // sibling
    TreeNode firstChild();

    interface Visitor {
        void visit(TreeNode node);
    }

    void visitDepthFirstPostOrder(Visitor visitor) {
        TreeNode owner =3D this;
        TreeNode end =3D owner.parent();
        TreeNode tmp, item =3D firstChild();

        do {
            while (item !=3D null) {
                // Check if this item has children
                while ((tmp =3D item.firstChild()) !=3D null) {
                    // Traverse down to next level
                    owner =3D item;
                    item =3D tmp;
                }
                // Visit item
                visitor.visit(item);
                // Traverse across to next sibling
                item =3D item.next();
            }
            // Visit owner
            visitor.visit(owner);
            // Traverse up to parent
            item =3D owner.next();
            owner =3D owner.parent();
        } while (owner !=3D end);
    }
}

Obviously, similar behavior could be implemented with a template =
function and a bounded parameter type (T:TreeNode).

I was actually thinking about mixins and how they might be added to D, =
but I think the notion of a stateless, behavioral mixin (as in the =
TreeNode interface above) might be useful and relatively easy to =
implement as it doesn't rely on multiple inheritance of state.

As for terminology, one might group interface member functions into:

- primitive functions (declared, abstract)
- derived functions (defined, implemented)

Matthias