this is a very nice explanation of the whole issue. Is there a place where we could put this on the website? I think it would be nice for people joining classpath to find documentation why we have to do it this roundabout way.
Ingo
Thomas Fitzsimmons wrote:
Hello,
This patch fixes the way we handle "alias" methods in the AWT, where a public or protected method has been deprecated in favour of a new one that has the same function but a different name. Sun does this a fair amount to fix cases where the original method's name did not follow their naming conventions.
Unfortunately, this practise complicates class library code that calls these aliased methods. Library code must still call the deprecated method so that old client code that overrides it continues to work. But library code must also call the new version, because new code is expected to override the new method.
The correct way to handle this (and the way Sun does it) may seem counterintuitive because it means that new code is less efficient than old code: the new method must call the deprecated method, and throughout the library code calls to the old method must be replaced with calls to the new one.
Take the example of a newly-written container laying out a component and
wanting to know its preferred size. The Component class has a
deprecated preferredSize method and a new method, getPreferredSize. Assume that the container is laying out an old component that overrides
preferredSize and a new component that overrides getPreferredSize. If
the container calls getPreferredSize and the default implementation of
getPreferredSize calls preferredSize, then the old component will have
its preferredSize method called and new code will have its
getPreferredSize method called.
Even using this calling scheme, an old component may still be laid out improperly if it implements a method, getPreferredSize, that has the same signature as the new Component.getPreferredSize. But that is a general problem -- adding new public or protected methods to a widely-used class that calls those methods internally is risky, because existing client code may have already declared methods with the same signature.
The solution may still seem counterintuitive -- why not have the deprecated method call the new method, then have the library always call the old method. One problem with that, using the preferred size example again, is that new containers, which will use the non-deprecated getPreferredSize, will not get the preferred size of old components.
Jeroen Frijters provides a good explanation of the problem in his IKVM web log [1].
Comments?
Tom
[1] GridBagLayout and more AWT, http://weblog.ikvm.net/commentview.aspx?guid=8B14C003-E16A-4E99-A52E-AD776CBB8CBF
2004-02-02 Thomas Fitzsimmons <[EMAIL PROTECTED]>
[Patch was here ...]
-- Ingo Pr�tel [EMAIL PROTECTED] aicas GmbH http://www.aicas.com Haid-und-Neu-Str. 18 phone +49 721 663 968-32 76131 Karlsruhe fax +49 721 663 968-93 Germany
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
