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

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

Re: @java.lang.DontOverride

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#28430 — Re: @java.lang.DontOverride

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.

[toc] | [next] | [standalone]

#28447

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.

[toc] | [prev] | [next] | [standalone]

#28451

On 5/12/2014 8:25 AM, Daniel Pitts wrote:
> 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.

I think we're in agreement here, at least up to the "reasonable" bit.

>>
>> 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.

I don't understand what this means.  If I understand correctly, Stefan 
doesn't want the semantics of his "isValid()" method to change.  That's 
the class to be extended, the JComponent.  That's where he want's to put 
the "don't override" annotation.

The extending class, the subclass, is only involved here if it 
mistakenly changes the semantics of "isValid()".  Putting a "don't 
override" in the extended class is too late.

> Stefan, I think the real answer is "Don't add non-private methods to
> your JComponent extension."

This doesn't seem practical.  I've extended JComponent classes before, 
I'm just careful to read the existing documentation for those classes 
and I make sure to not change any semantics I don't want changed.  I 
can't think of any other way to do this.

> 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.

I'd like to know more about what problem Stefan is actually trying to 
solve.  His question is highly theoretical to me since there's really no 
context or goal other than "I wish this thing worked differently."

[toc] | [prev] | [next] | [standalone]

#28473

On Mon, 12 May 2014 08:25:58 -0700, Daniel Pitts wrote:

> 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.

IOW, "prefer composition to inheritance".

Further to that, you might want to use a private inner class that extends 
JComponent and has direct access to the enclosing object. You'd have a 
factory method in the outer class that returns either a new instance or 
*the* instance (perhaps lazily created), depending on whether you want to 
limit to one instance.

Alternatively ... if your non-component logic has to do with some program 
state that the component displays and/or allows the user to manipulate, 
then you should probably separate it out into a model object and make the 
JComponent subclass a view object, similar to the existing ListModel and 
various list controls (JList, JComboBox, ...).

[toc] | [prev] | [next] | [standalone]

#28474

On 5/14/2014 10:12 AM, Sarah Connor wrote:

> Alternatively ... if your non-component logic has to do with some program
> state that the component displays and/or allows the user to manipulate,
> then you should probably separate it out into a model object and make the
> JComponent subclass a view object, similar to the existing ListModel and
> various list controls (JList, JComboBox, ...).
>


This is what I would prefer.  MVC is neither composition nor 
inheritance.  It just makes separate classes which aren't related and 
have no knowledge of each other.  This is vastly superior in many cases.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web