Covariant Return Types and ECS

John Ky Tue, 8 Feb 2000 20:29:52 -0800
Hi List:

I have a suggestion for ECS.

When trying to subclass some element classes,
I noticed that methods such as addElement could
not be overridden properly.  Overriding these methods
requires covariant return types - a feature not yet
implemented in the Java Language.  Currently, the
compiler just falls over - complaining that two methods
differ in return types only, regardless of the fact that
one of the return types is a subclass of another.

For example:

__1__
    class Body2 extends Body {
        Body2 addElement(Element element)
        {
            // Do some new stuff
            super.addElement(element);
            // Some more stuff
        }
        
        Body2 setFoo() { /* ... */ }
    }

fails.  Instead, the following code works:

__2__
    class Body2 extends Body {
        Body addElement(Element element)
        {
            // Do some new stuff
            super.addElement(element);
            // Some more stuff
        }
        
        Body2 setFoo() { /* ... */ }
    }

however, this means that access to Body2's additional
methods (eg. setFoo(int foo)) become inaccessible
after a call to addElement.  That is to say, the following
is legal:

__3__
new Body2()
    .setFoo()
    .addElement (new P('Hello World'));

Yet the following is illegal:

__4__
    new Body2()
        .addElement (new P('Hello World'))
        .setFoo();

So until Java implements covariant return types,
the extensibility of ECS is compromised.
___________________________

I think there is a possible work around.

We could replace methods like

    Body addElement(Element element)

with:

    Body addElement(Element element, Body _null)

With this change, we can subclass Body like this:

__5__
    class Body2 extends Body {
        /**
         * @param element - the element to add
         * @param _null - must be null
         */
        Body2 addElement(Element element, Body2 _null)
        {
            // Do some new stuff
            super.addElement(element);
            // Some more stuff
        }
        
        Body2 setFoo() { /* ... */ }
    }

Unlike 1, this is legal because the arguments types of the
overloading method is different from that of the original method.

Hence the new class can be used as follows:

__6__
    new Body2()
        .addElement(new P('Hello World'), null)
        .setFoo();

Unfortunately it is a little bit more wordy and I don't know
if this behaviour is consistant across all compilers/JVMs.
(I very much hope so)

Many people might object to the different notation
and the wordiness of it all, but it is a suggestion.

I think the currently non-extensibile nature of these
methods act as a hurdle to building additional layers
above ECS.  There may be even more critical
extensibility problems with other methods that I
haven't used yet, but which you know about - so
it could be a worthwhile compromise.

John


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


--
------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Archives and Other:  <http://java.apache.org/main/mail.html>
Problems?:           [EMAIL PROTECTED]
Covariant Return Types and ECS

Reply via email to
