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

Re: @java.lang.DontOverride

Path	csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx11.iad.POSTED!not-for-mail
From	Daniel Pitts <newsgroup.nospam@virtualinfinity.net>
User-Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version	1.0
Newsgroups	comp.lang.java.programmer
Subject	Re: @java.lang.DontOverride
References	<override-20140511031054@ram.dialup.fu-berlin.de> <lkmkeg$qko$1@dont-email.me>
In-Reply-To	<lkmkeg$qko$1@dont-email.me>
Content-Type	text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding	8bit
Lines	41
Message-ID	<1K5cv.7545$s87.2913@fx11.iad> (permalink)
X-Complaints-To	abuse@newsrazor.net
NNTP-Posting-Date	Mon, 12 May 2014 15:25:49 UTC
Date	Mon, 12 May 2014 08:25:58 -0700
X-Received-Bytes	2641
X-Received-Body-CRC	3185411266
Xref	csiph.com comp.lang.java.programmer:28447

Show key headers only | View raw

On 5/10/14 6:40 PM, markspace wrote:
> 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.
>
[snip]
> 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.
I think his point is that if "isValid" becomes a member of JComponent, 
he wants a compiler error so that he knows his implementation may now 
have different semantics than intended.  This is to say "My code is now 
broken because of an interface change in JComponent."  That is a 
reasonable thing to want to know.
>
> 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.
This is for defining a class that is to be extended, not for defining 
the extending class.


Stefan, I think the real answer is "Don't add non-private methods to 
your JComponent extension."  Instead, create a different class that 
provides a JComponent object (perhaps a getComponent() method). All of 
the "business" logic that affects the component will live in your 
non-component class, or in the appropriate standard methods of your 
component class.



HTH,
Daniel.

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