Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #28430

Re: @java.lang.DontOverride

From markspace <markspace@nospam.nospam>
Newsgroups comp.lang.java.programmer
Subject Re: @java.lang.DontOverride
Date 2014-05-10 18:40 -0700
Organization A noiseless patient Spider
Message-ID <lkmkeg$qko$1@dont-email.me> (permalink)
References <override-20140511031054@ram.dialup.fu-berlin.de>

Show all headers | View raw


On 5/10/2014 6:16 PM, Stefan Ram wrote:
> class Example extends javax.swing.JComponent
> { public boolean isValid(){ return true; }}
>
>    I do not want to override any method of JComponent with my method.
>    I just want to add a new method. But now or in future versions of
>    Swing there might be an »isValid« method in JComponent.

Yeah, I see what you are saying, I believe, but now we're getting into 
C++ territory:  "A keyword and semantics for every corner-case imaginable."

So if you have a interface "BillingInvoice" with an "isValid()" method, 
and you add that interface to a subclass of JComponent, you want 
something like C++ where you can differentiate which method gets called:

   component.JComponent::isValid();
vs.
   component.BillingInvoice::isValid();

I realize that's not what you said, but that's the next logical step. 
Your issue can be fixed just by reading the API carefully.  Don't make 
classes where the method names conflict.

Moreover, I find your request questionable.  How do you know what 
methods should never ever be overridden in future classes?  How do you 
know someone won't make a new interface for JComponent, some 
ImprovedJComponent, where the "isValid()" method needs to be overridden 
by the new classes?  It's too hard to predict the future like this. 
Just require that your coders learn to read, and especially test, their 
code and problems like this become manageable.

The keyword "final" is there for the correct behavior of the current 
class;  that's something you can reasonable predict.  Leave the correct 
behavior of future classes to future coders.

Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar | Unroll thread


Thread

Re: @java.lang.DontOverride markspace <markspace@nospam.nospam> - 2014-05-10 18:40 -0700
  Re: @java.lang.DontOverride Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-05-12 08:25 -0700
    Re: @java.lang.DontOverride markspace <markspace@nospam.nospam> - 2014-05-12 10:11 -0700
    Re: @java.lang.DontOverride Sarah Connor <s.connor@gmail.invalid> - 2014-05-14 17:12 +0000
      Re: @java.lang.DontOverride markspace <markspace@nospam.nospam> - 2014-05-14 10:18 -0700

csiph-web