Name: ssT124754 Date: 03/27/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

How about adding a keyword called "expose" that takes an
interface handle as a paramater?

IMyInterface myVariable;
expose myVariable;

This would be a rather simple addition to the language which would have rather
profound implications based on the way programmers think.

All this keyword need do is indicate to the compiler that the user is
exposing an interface and delegating to the specified handle. So, if my
interface has one method in the above example called myMethod(), the byte
code compiler would expose the interface and delegate to the selected handle.

public void myMethod()
{
  myVariable.myMethod();
}

I think this addition would be great from a number of angles. It'd take about
an afternoon for a Sun developer to implement but would very much encourage the
proper use of interfaces in Java development. One can easily conceive of
developers creating libraries of interfaces that they could use to simply snap
together components without the overhead of reflection or any other runtime
proxy.

If, for example, I create a IO object that exposes both a table and tree
interface for use in Swing. Each of those Swing interfaces comprise some 5 to
10 different methods. That means I have to hand code all the delegation. Of
course, I could write my own simple parser to read my file looking for such
an "expose" keyword to write into the Java file but that's not what I'm after.

In the above example, instead of having ten to fifteen extra methods in my file
do nothing but delegating to an object of a given interface, I'd have nothing
but:

expose MutableTableNode myTableObj;
expose MutableTreeNode myTreeNode;

In a current project I have a DefaultMutableTreeNode that I hold by composition
in another object. Unfortunately I expose the objects interface and that means
I have to implement all the mutable methods (shown below.) This fact actually
works against encouraging composition and use of interfaces.

That simple mechanism would be enough but if I could then also override a
delegated method by implementing tha method in my concrete class, so much the
better. So, if I always wanted the child count to be reported as -1 (for
whatever reason), I'd use the expose keyword as specified above and then
override the method:

public int getChildCount()
{
        return -1;
}

Perhaps that would also need to indicate that it is part of the exposed group
so that the compiler might recognize it, such as:

exposed public int getChildCount()
{
        return -1;
}

So, this keyword would encourage (a) the use of interfaces, (b) the use of
composition, and (c) design philosohphies and patterns that facilitated
snapping together objects.

This isn't a radical change but would represent, I think, a breakthrough in
thinking for many programmers.




* the methods of TreeNode and MutableTreeNode are implemented here as delegation
* to an internally constructed/private DefaultMutableTreeNode. The IDCITreeNode
* interface adds one method that allows for adding a node.
 */
 
    /**
     * Returns the child <code>TreeNode</code> at index
     * <code>childIndex</code>.
     */
    public TreeNode getChildAt(int childIndex)
    {
        return myTreeNode.getChildAt(childIndex);
        
    }
    

    /**
     * Returns the number of children <code>TreeNode</code>s the receiver
     * contains.
     */
    public int getChildCount()
    {
        return myTreeNode.getChildCount();
    }
    
    /**
     * Returns the parent <code>TreeNode</code> of the receiver.
     */
    public TreeNode getParent()
    {
        return myTreeNode.getParent();
    }
    
    /**
     * Returns the index of <code>node</code> in the receivers children.
     * If the receiver does not contain <code>node</code>, -1 will be
     * returned.
     */
    public int getIndex(TreeNode node)
    {
        return myTreeNode.getIndex(node);
    }
    

    /**
     * Returns true if the receiver allows children.
     */
    public boolean getAllowsChildren()
    {
        return myTreeNode.getAllowsChildren();
    }
    

    /**
     * Returns true if the receiver is a leaf.
     */
    public boolean isLeaf()
    {
        return myTreeNode.isLeaf();
    }
    

    /**
     * Returns the children of the reciever as an Enumeration.
     */
    public Enumeration children()
    {
        return myTreeNode.children();
    }
    
    /**
     * Adds <code>child</code> to the receiver at <code>index</code>.
     * <code>child</code> will be messaged with <code>setParent</code>.
     */
    public void insert(MutableTreeNode child, int index)
    {
        myTreeNode.insert(child, index);
    }
    

    /**
     * Removes the child at <code>index</code> from the receiver.
     */
    public void remove(int index)
    {
         myTreeNode.remove(index);
    }
    

    /**
     * Removes <code>node</code> from the receiver. <code>setParent</code>
     * will be messaged on <code>node</code>.
     */
    public void remove(MutableTreeNode node)
    {
         myTreeNode.remove(node);
    }
    

    /**
     * Resets the user object of the receiver to <code>object</code>.
     */
    public void setUserObject(Object object)
    {
        myTreeNode.setUserObject(object);
    }
    

    /**
     * Removes the receiver from its parent.
     */
    public void removeFromParent()
    {
        myTreeNode.removeFromParent();
    }
    

    /**
     * Sets the parent of the receiver to <code>newParent</code>.
     */
    public void setParent(MutableTreeNode newParent)
    {
        myTreeNode.removeFromParent();
    }
    
    public void add(MutableTreeNode child)
    {
        myTreeNode.add(child);
        utility.getTree().revalidate();
        utility.getTree().repaint();
    }
(Review ID: 119535)
======================================================================