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

Re: @java.lang.DontOverride

Path	csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From	markspace <markspace@nospam.nospam>
Newsgroups	comp.lang.java.programmer
Subject	Re: @java.lang.DontOverride
Date	Sat, 10 May 2014 18:40:27 -0700
Organization	A noiseless patient Spider
Lines	36
Message-ID	<lkmkeg$qko$1@dont-email.me> (permalink)
References	<override-20140511031054@ram.dialup.fu-berlin.de>
Mime-Version	1.0
Content-Type	text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding	8bit
Injection-Date	Sun, 11 May 2014 01:40:33 +0000 (UTC)
Injection-Info	mx05.eternal-september.org; posting-host="9358cda03e1e0dfd3c4b757daa608707"; logging-data="27288"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/MqV0RnWj0PTq5YeJN0kHuPiCKEh72Xhs="
User-Agent	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
In-Reply-To	<override-20140511031054@ram.dialup.fu-berlin.de>
Cancel-Lock	sha1:iV2QTOjhjQYc0w1Fm7/pDSsYhkg=
Xref	csiph.com comp.lang.java.programmer:28430

Show key headers only | 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