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

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

Re: @java.lang.DontOverride

Show all headers | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | 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