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

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

@Override

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

Contents

  @Override bob smith <bob@coolfone.comze.com> - 2012-07-23 11:30 -0700
    Re: @Override Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-23 20:52 +0200
    Re: @Override markspace <-@.> - 2012-07-23 11:54 -0700
      Re: @Override Lew <lewbloch@gmail.com> - 2012-07-23 13:05 -0700
      Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-23 19:54 -0400
    Re: @Override "John B. Matthews" <nospam@nospam.invalid> - 2012-07-23 15:56 -0400
      Re: @Override Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-07-23 14:19 -0700
        Re: @Override rossum <rossum48@coldmail.com> - 2012-07-24 13:09 +0100
          Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-24 21:29 -0400
        Re: @Override Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-24 09:04 -0400
    Re: @Override Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-23 16:35 -0400
      Re: @Override Lew <lewbloch@gmail.com> - 2012-07-23 13:59 -0700
        Re: @Override Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-23 23:40 +0200
          Re: @Override Lew <lewbloch@gmail.com> - 2012-07-23 14:51 -0700
            Re: @Override Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-24 00:08 +0200
              Re: @Override Lew <lewbloch@gmail.com> - 2012-07-23 16:57 -0700
        Re: @Override Robert Klemme <shortcutter@googlemail.com> - 2012-07-24 09:46 +0200
      Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-23 19:58 -0400
        Re: @Override Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-23 22:16 -0400
          Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-23 22:57 -0400
            Re: @Override Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-23 23:47 -0400
              Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-24 21:35 -0400
      Re: @Override Jim Janney <jjanney@shell.xmission.com> - 2012-07-26 20:00 -0600
    Re: @Override Gene Wirchenko <genew@ocis.net> - 2012-07-23 14:01 -0700
    Re: @Override Silvio Bierman <silvio@moc.com> - 2012-07-24 00:22 +0200
      Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-23 19:53 -0400
        Re: @Override Gene Wirchenko <genew@ocis.net> - 2012-07-23 18:59 -0700
        Re: @Override Silvio Bierman <silvio@moc.com> - 2012-07-24 22:57 +0200
          Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-24 21:24 -0400
      Re: @Override Robert Klemme <shortcutter@googlemail.com> - 2012-07-24 15:36 +0200
        Re: @Override Gene Wirchenko <genew@ocis.net> - 2012-07-24 09:54 -0700
        Re: @Override Silvio Bierman <silvio@moc.com> - 2012-07-24 23:14 +0200
          Re: @Override Robert Klemme <shortcutter@googlemail.com> - 2012-07-25 07:57 +0200
            Re: @Override Gene Wirchenko <genew@ocis.net> - 2012-07-25 10:34 -0700
            Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-25 14:54 -0400
              Re: @Override Wanja Gayk <brixomatic@yahoo.com> - 2012-07-30 14:42 +0200
        Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-24 21:20 -0400
          Re: @Override Lew <noone@lewscanon.com> - 2012-07-25 06:26 -0700
            Re: @Override Arne Vajhøj <arne@vajhoej.dk> - 2012-07-25 17:16 -0400
    Re: @Override Roedy Green <see_website@mindprod.com.invalid> - 2012-07-23 20:59 -0700
    Re: @Override Wanja Gayk <brixomatic@yahoo.com> - 2012-07-24 16:06 +0200

Page 1 of 3  [1] 2 3  Next page →

#16253 — @Override

Is it really necessary to write @Override when you override or is this just "a good thing"?

[toc] | [next] | [standalone]

#16255

On 23/07/2012 20:30, bob smith allegedly wrote:
> Is it really necessary to write @Override when you override or is this just "a good thing"?

Just a good thing. Catches cases where you aren't actually overriding.

-- 
DF.

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

#16256

On 7/23/2012 11:30 AM, bob smith wrote:
> Is it really necessary to write @Override when you override or is
> this just "a good thing"?
>


Well, it's "just a good thing," but it's *really* a good thing.  If you 
were programming professionally, you'd expect your boss (or coworkers, 
say during a code review) to insist that you use @Override wherever 
appropriate.

In short, "just do it."

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

#16261

markspace wrote:
> bob smith wrote:
> Is it really necessary to write @Override when you override or is
> this just "a good thing"?

Since when does "a good thing" ever deserve a "just"?

If it's a good thing, what's your objection?

Did you read the docs on '@Override'?

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.4>
<http://docs.oracle.com/javase/7/docs/api/java/lang/Override.html>

Why not?

Seriously, why in the world would you not want to use '@Override'?

Based on the documentation, now that you're aware of it, rephrase 
your question as "What are the advantages and disadvantages of 
'@Override'?" Then evaluate its utility.

> Well, it's "just [sic] a good thing," but it's *really* a good thing.  If you 
> were programming professionally, you'd expect your boss (or coworkers, 
> say during a code review) to insist that you use @Override wherever 
> appropriate.
> 
> In short, "just do it."

OP: There is benefit to using '@Override' and serious risk of harm if you don't.

Consider 'Object#equals()'.

public class BadEquals
{
  private String attribute = "";
  public String getAttribute() { return attribute; }
  public void setAttribute(String attr) { this.attribute = (attr == null? "" : attr); }
  public boolean equals(BadEquals other)
  {
    if (this == other)
    {
      return true;
    }
    if (other == null)
    {
      return false;
    }
   return getAttribute().equals(other.getAttribute());
  }
}

Let's say you have another class that uses a collection of 'BadEquals'. 

Without '@Override', as shown above, you won't catch that bug until 
runtime.

With it, you'll catch it at compile time.

-- 
Lew

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

#16277

On 7/23/2012 2:54 PM, markspace wrote:
> On 7/23/2012 11:30 AM, bob smith wrote:
>> Is it really necessary to write @Override when you override or is
>> this just "a good thing"?
>
> Well, it's "just a good thing," but it's *really* a good thing.  If you
> were programming professionally, you'd expect your boss (or coworkers,
> say during a code review) to insist that you use @Override wherever
> appropriate.

I think that it would slip through code reviews in many places.

I agree that it is a good thing.

Arne

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

#16260

In article <75036e8b-8b5f-4ea4-aef7-c063249f5707@googlegroups.com>,
 bob smith <bob@coolfone.comze.com> wrote:

> Is it really necessary to write @Override when you override or is 
> this just "a good thing"?

So good, in fact, that another strongly-typed language added a very 
similar check at about the same time.

<http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-2-7.html>
<http://www.adaic.org/resources/add_content/standards/05rm/html/RM-8-3-1.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

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

#16268

On Mon, 23 Jul 2012 15:56:12 -0400, John B. Matthews wrote:

> In article <75036e8b-8b5f-4ea4-aef7-c063249f5707@googlegroups.com>,
>  bob smith <bob@coolfone.comze.com> wrote:
> 
>> Is it really necessary to write @Override when you override or is 
>> this just "a good thing"?
> 
> So good, in fact, that another strongly-typed language added a very 
> similar check at about the same time.
> 
> <http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-2-7.html>
> <http://www.adaic.org/resources/add_content/standards/05rm/html/RM-8-3-1.html>

Indeed, one of the languages most heavily inspired by Java (at least
initially) incorporated the concept at the outset. C# requires the use of
"override" when overriding, and strongly encourages "new" if hiding.

At the same time, methods default to non-virtual in C#, so arguably C#
could have got along just fine without "override". But it's there, and is
useful.

I will admit that the number of times it's helped me avoid a mistake are
far and few between. But it's happened, and it's certainly no large
inconvenience to have to include "override" (in fact, at least with the
Visual Studio IDE, it's a convenience, as VS will pop up a list of
overridable methods, and then auto-generate a skeleton method to fill in
for the override...maybe Eclipse, NetBeans, etc. would do the same?).

Pete

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

#16300

On Mon, 23 Jul 2012 14:19:16 -0700, Peter Duniho
<NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:

>in fact, at least with the Visual Studio IDE, it's a convenience, as 
>VS will pop up a list of overridable methods, and then auto-generate 
>a skeleton method to fill in for the override...maybe Eclipse, 
>NetBeans, etc. would do the same?
NetBeans does that: Alt+Insert or right click and select "Insert
Code".  I don't use Eclipse, so I can't comment on that IDE.

rossum

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

#16329

On 7/24/2012 8:09 AM, rossum wrote:
> On Mon, 23 Jul 2012 14:19:16 -0700, Peter Duniho
> <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>> in fact, at least with the Visual Studio IDE, it's a convenience, as
>> VS will pop up a list of overridable methods, and then auto-generate
>> a skeleton method to fill in for the override...maybe Eclipse,
>> NetBeans, etc. would do the same?
> NetBeans does that: Alt+Insert or right click and select "Insert
> Code".  I don't use Eclipse, so I can't comment on that IDE.

right click
refactor
override/implements methods
pick what one want

Arne

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

#16301

On 7/23/2012 5:19 PM, Peter Duniho wrote:
>[...]
> I will admit that the number of times it's helped me avoid a mistake are
> far and few between. But it's happened, and it's certainly no large
> inconvenience to have to include "override" (in fact, at least with the
> Visual Studio IDE, it's a convenience, as VS will pop up a list of
> overridable methods, and then auto-generate a skeleton method to fill in
> for the override...maybe Eclipse, NetBeans, etc. would do the same?).

     NetBeans will do two things about @Override (maybe more). It
will flag an overriding method that lacks an @Override annotation
and suggest that you add it (which you can do with a shortcut).
A feature I find even more convenient is that it notices when you
attempt to intantiate an abstract class, and suggests that you
provide overrides for the missing methods.  Another shortcut, and
presto! it writes skeletons for the missing methods, with @Override
already in place.  Saves the bother of hunting up the exact spelling
of a method name.

     Illustration: If I type

	button.addActionListener(new ActionListener(){});

... NetBeans tells me I've failed to implement abstract methods.
After Alt-Enter and a confirming Enter, it rewrites my code as

	button.addActionListener(new ActionListener() {
	    @Override
	    public void actionPerformed(ActionEvent e) {
	        throw new UnsupportedOperationException(
	            "Not supported yet.");
	    }
	});

... which I find very helpful, especially for interfaces that
have several abstract methods.  (I've even been known to let
NetBeans expand MouseListener, then change it to MouseAdapter
and delete the auto-written methods I don't care about, just
to be sure I've got everything spelled properly.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#16264

On 7/23/2012 2:30 PM, bob smith wrote:
> Is it really necessary to write @Override when you override or is this just "a good thing"?

     Two benefits of @Override appear to me, one from its presence
and one from its absence:

     - If you write @Override and then misspell the method name or
       mess up the parameter list, Java will say "Hey, wait: There's
       nothing in the superclass with this signature; what do you
       think you're doing?"  And then you'll say "Oops!" and fix
       the problem, instead of wondering why your "overriding" method
       doesn't seem to work.

     - If you write a method and your IDE starts suggesting that you
       ought to tag it with @Override, you'll be alerted that you've
       overridden something you didn't intend to.[*]

     Two benefits; that's all I see.  Hence, like indentation and
Javadoc comments, not "really necessary" ...

     [*] This actually happened to me earlier today.  I was writing
a little Swing doodad to edit the "locations" of inventory items,
and I gave it a getLocation() method.  NetBeans started clamoring
for @Override, and I realized that my doodad extended JPanel which
in turn extended JComponent, which already has a getLocation() ...
Time for "Facepalm!" and a quick name change.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#16267

Eric Sosman wrote:
> bob smith wrote:
>> Is it really necessary to write @Override when you override or is this just "a good thing"?
> 
>      Two benefits of @Override appear to me, one from its presence
> and one from its absence:
> 
>      - If you write @Override and then misspell the method name or
>        mess up the parameter list, Java will say "Hey, wait: There's
>        nothing in the superclass with this signature; what do you
>        think you're doing?"  And then you'll say "Oops!" and fix
>        the problem, instead of wondering why your "overriding" method
>        doesn't seem to work.
> 
>      - If you write a method and your IDE starts suggesting that you
>        ought to tag it with @Override, you'll be alerted that you've
>        overridden something you didn't intend to.[*]
> 
>      Two benefits; that's all I see.  Hence, like indentation and

And that wasn't enough?

Add the third benefit that I mentioned upthread. Aren't they enough now?

Is your disparaging tone rhetorical, or do you really find the 
benefit of '@Override' to be that marginal?

Because it isn't.

> Javadoc comments, not "really necessary" ...

Dental patient:
  Is flossing my teeth really necessary? Which ones do 
  *really* need to floss?

Dentist:
  Just the ones you want to keep!

>      [*] This actually happened to me earlier today.  I was writing
> a little Swing doodad to edit the "locations" of inventory items,
> and I gave it a getLocation() method.  NetBeans started clamoring
> for @Override, and I realized that my doodad extended JPanel which
> in turn extended JComponent, which already has a getLocation() ...
> Time for "Facepalm!" and a quick name change.

That is an excellent anecdote to support the idea that the 
'@Override' annotation is really necessary.

But only where you want to catch bugs at compile time before 
they bite you in production.

-- 
Lew

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

#16269

On 23/07/2012 22:59, Lew allegedly wrote:
> Eric Sosman wrote:
>> bob smith wrote:
>>> Is it really necessary to write @Override when you override or is this just "a good thing"?
>>
>>      Two benefits of @Override appear to me, one from its presence
>> and one from its absence:
>>
>>      - If you write @Override and then misspell the method name or
>>        mess up the parameter list, Java will say "Hey, wait: There's
>>        nothing in the superclass with this signature; what do you
>>        think you're doing?"  And then you'll say "Oops!" and fix
>>        the problem, instead of wondering why your "overriding" method
>>        doesn't seem to work.
>>
>>      - If you write a method and your IDE starts suggesting that you
>>        ought to tag it with @Override, you'll be alerted that you've
>>        overridden something you didn't intend to.[*]
>>
>>      Two benefits; that's all I see.  Hence, like indentation and
> 
> And that wasn't enough?
> 
> Add the third benefit that I mentioned upthread. Aren't they enough now?
> 
> Is your disparaging tone rhetorical, or do you really find the 
> benefit of '@Override' to be that marginal?
> 
> Because it isn't.
> 
>> Javadoc comments, not "really necessary" ...
> 
> Dental patient:
>   Is flossing my teeth really necessary? Which ones do 
>   *really* need to floss?
> 
> Dentist:
>   Just the ones you want to keep!
> 
>>      [*] This actually happened to me earlier today.  I was writing
>> a little Swing doodad to edit the "locations" of inventory items,
>> and I gave it a getLocation() method.  NetBeans started clamoring
>> for @Override, and I realized that my doodad extended JPanel which
>> in turn extended JComponent, which already has a getLocation() ...
>> Time for "Facepalm!" and a quick name change.
> 
> That is an excellent anecdote to support the idea that the 
> '@Override' annotation is really necessary.
> 
> But only where you want to catch bugs at compile time before 
> they bite you in production.
> 

Uh... there was a (pretty long) time when people and programs *did*
manage to exist without that annotation, you know. No need to be overly
dramatic.

-- 
DF.

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

#16270

On Monday, July 23, 2012 2:40:21 PM UTC-7, Daniele Futtorovic wrote:
> On 23/07/2012 22:59, Lew allegedly wrote:
> > Eric Sosman wrote:
> >> bob smith wrote:
> >>> Is it really necessary to write @Override when you override or is this just "a good thing"?
> >>
> >>      Two benefits of @Override appear to me, one from its presence
> >> and one from its absence:
> >>
> >>      - If you write @Override and then misspell the method name or
> >>        mess up the parameter list, Java will say "Hey, wait: There's
> >>        nothing in the superclass with this signature; what do you
> >>        think you're doing?"  And then you'll say "Oops!" and fix
> >>        the problem, instead of wondering why your "overriding" method
> >>        doesn't seem to work.
> >>
> >>      - If you write a method and your IDE starts suggesting that you
> >>        ought to tag it with @Override, you'll be alerted that you've
> >>        overridden something you didn't intend to.[*]
> >>
> >>      Two benefits; that's all I see.  Hence, like indentation and
> > 
> > And that wasn't enough?
> > 
> > Add the third benefit that I mentioned upthread. Aren't they enough now?
> > 
> > Is your disparaging tone rhetorical, or do you really find the 
> > benefit of '@Override' to be that marginal?
> > 
> > Because it isn't.
> > 
> >> Javadoc comments, not "really necessary" ...
> > 
> > Dental patient:
> >   Is flossing my teeth really necessary? Which ones do 
> >   *really* need to floss?
> > 
> > Dentist:
> >   Just the ones you want to keep!
> > 
> >>      [*] This actually happened to me earlier today.  I was writing
> >> a little Swing doodad to edit the "locations" of inventory items,
> >> and I gave it a getLocation() method.  NetBeans started clamoring
> >> for @Override, and I realized that my doodad extended JPanel which
> >> in turn extended JComponent, which already has a getLocation() ...
> >> Time for "Facepalm!" and a quick name change.
> > 
> > That is an excellent anecdote to support the idea that the 
> > '@Override' annotation is really necessary.
> > 
> > But only where you want to catch bugs at compile time before 
> > they bite you in production.
> > 
> 
> Uh... there was a (pretty long) time when people and programs *did*
> manage to exist without that annotation, you know. No need to be overly
> dramatic.

You sound like Grandpaw complaining that kids these days have it too easy.
"In my day, we had to check for ourselves whether the method overrode a 
parent method!"

Your irrelevant observation does not give a reason to eschew '@Override'.

The fact is that Java *does* have it, and it *is* useful for the class of bugs 
it helps prevent. 

A point you ignore in your rush to fallacious argumentation.

That languages (including Java itself) didn't used to have 
it is hardly an argument against it. In fact, that Java added it, given the 
language's resistance to change, is strong evidence in favor of it. 
So your evidence supports use of '@Override'. You drew exactly the 
opposite of the correct conclusion from your data.

-- 
Lew

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

#16271

On 23/07/2012 23:51, Lew allegedly wrote:
> On Monday, July 23, 2012 2:40:21 PM UTC-7, Daniele Futtorovic wrote:
>> Uh... there was a (pretty long) time when people and programs *did*
>> manage to exist without that annotation, you know. No need to be overly
>> dramatic.
> 
> You sound like Grandpaw complaining that kids these days have it too easy.
> "In my day, we had to check for ourselves whether the method overrode a 
> parent method!"
> 
> Your irrelevant observation does not give a reason to eschew '@Override'.
> 
> The fact is that Java *does* have it, and it *is* useful for the class of bugs 
> it helps prevent. 
> 
> A point you ignore in your rush to fallacious argumentation.
> 
> That languages (including Java itself) didn't used to have 
> it is hardly an argument against it. In fact, that Java added it, given the 
> language's resistance to change, is strong evidence in favor of it. 
> So your evidence supports use of '@Override'. You drew exactly the 
> opposite of the correct conclusion from your data.

And you sound like a drama queen. The fact that Java programs existed at
a point where @Override didn't exist proves that this annotation is not
strictly necessary. And the assiduous JLS reader that you are should
know that this hasn't changed.

Is that annotation a good thing? Yes. Should it be used? Absolutely.

As a matter of fact, its merits are such that with a minimum of
explanation, any sensible person would adopt it on their own. No need to
exaggerate or dramatize the issue. No need to try to ridicule me for
refusing your dramatization. Attempts like that to use coercion rather
than reason are counter-productive.

-- 
DF.

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

#16278

On Monday, July 23, 2012 3:08:04 PM UTC-7, Daniele Futtorovic wrote:
> On 23/07/2012 23:51, Lew allegedly wrote:
> > On Monday, July 23, 2012 2:40:21 PM UTC-7, Daniele Futtorovic wrote:
> >> Uh... there was a (pretty long) time when people and programs *did*
> >> manage to exist without that annotation, you know. No need to be overly
> >> dramatic.
> > 
> > You sound like Grandpaw complaining that kids these days have it too easy.
> > "In my day, we had to check for ourselves whether the method overrode a 
> > parent method!"
> > 
> > Your irrelevant observation does not give a reason to eschew '@Override'.
> > 
> > The fact is that Java *does* have it, and it *is* useful for the class of bugs 
> > it helps prevent. 
> > 
> > A point you ignore in your rush to fallacious argumentation.
> > 
> > That languages (including Java itself) didn't used to have 
> > it is hardly an argument against it. In fact, that Java added it, given the 
> > language's resistance to change, is strong evidence in favor of it. 
> > So your evidence supports use of '@Override'. You drew exactly the 
> > opposite of the correct conclusion from your data.
> 
> And you sound like a drama queen. The fact that Java programs existed at

Ad hominem argument.

> a point where @Override didn't exist proves that this annotation is not
> strictly necessary. And the assiduous JLS reader that you are should
> know that this hasn't changed.

I'm sorry, but where did I claim that the annotation is strictly necessary?

You're refuting a claim not made.

Straw-man argument.

> Is that annotation a good thing? Yes. Should it be used? Absolutely.

So we agree.

> As a matter of fact, its merits are such that with a minimum of
> explanation, any sensible person would adopt it on their own. No need to
> exaggerate or dramatize the issue. No need to try to ridicule me for
> refusing your dramatization. Attempts like that to use coercion rather
> than reason are counter-productive.

Like calling me names?

Physician, cure thyself.

-- 
Lew

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

#16298

On 23.07.2012 22:59, Lew wrote:
> Add the third benefit that I mentioned upthread. Aren't they enough now?

Are variant of this is where the super class or interface is in a 
library and a later version removed the method.  You'll immediately 
notice when replacing the lib with the newer version.  This is a good 
thing (being noticed - not removing something from a public API) and you 
are immediately aware that your method won't be invoked the same way as 
it used to be.

Granted this should be a rare situation but - for example - if the 
library method had been deprecated and you somehow missed adjusting your 
code to the imminent removal the compiler will force it on you once it 
is gone.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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

#16279

On 7/23/2012 4:35 PM, Eric Sosman wrote:
> On 7/23/2012 2:30 PM, bob smith wrote:
>> Is it really necessary to write @Override when you override or is this
>> just "a good thing"?
>
>      Two benefits of @Override appear to me, one from its presence
> and one from its absence:
>
>      - If you write @Override and then misspell the method name or
>        mess up the parameter list, Java will say "Hey, wait: There's
>        nothing in the superclass with this signature; what do you
>        think you're doing?"  And then you'll say "Oops!" and fix
>        the problem, instead of wondering why your "overriding" method
>        doesn't seem to work.
>
>      - If you write a method and your IDE starts suggesting that you
>        ought to tag it with @Override, you'll be alerted that you've
>        overridden something you didn't intend to.[*]
>
>      Two benefits; that's all I see.  Hence, like indentation and
> Javadoc comments, not "really necessary" ...

I see the biggest benefits being the documentation.

It can be important to know that ones method may be called
by the super class.

And all arguments seems related to extends not implements, so
I m not convinced that extending it to interface methods was
wise.

Arne

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

#16288

On 7/23/2012 7:58 PM, Arne Vajhøj wrote:
> On 7/23/2012 4:35 PM, Eric Sosman wrote:
>> On 7/23/2012 2:30 PM, bob smith wrote:
>>> Is it really necessary to write @Override when you override or is this
>>> just "a good thing"?
>>
>>      Two benefits of @Override appear to me, one from its presence
>> and one from its absence:
>>
>>      - If you write @Override and then misspell the method name or
>>        mess up the parameter list, Java will say "Hey, wait: There's
>>        nothing in the superclass with this signature; what do you
>>        think you're doing?"  And then you'll say "Oops!" and fix
>>        the problem, instead of wondering why your "overriding" method
>>        doesn't seem to work.
>>
>>      - If you write a method and your IDE starts suggesting that you
>>        ought to tag it with @Override, you'll be alerted that you've
>>        overridden something you didn't intend to.[*]
>>
>>      Two benefits; that's all I see.  Hence, like indentation and
>> Javadoc comments, not "really necessary" ...
>
> I see the biggest benefits being the documentation.
>
> It can be important to know that ones method may be called
> by the super class.
>
> And all arguments seems related to extends not implements, so
> I m not convinced that extending it to interface methods was
> wise.

    A separate @Implements annotation instead of @Override might
have been better for interfaces.  But what should one do about
abstract methods in abstract superclasses?  Are those @Override
or @Implements, or maybe @Concretizes?  And why should the class
with the actual implementation care about the distinction?  And
what about concrete methods *intended* to be overridden, as in
MouseAdapter?  @ProFormaOverrides?

     Looks like fodder for a "whichness of the why" debate.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#16292

On 7/23/2012 10:16 PM, Eric Sosman wrote:
> On 7/23/2012 7:58 PM, Arne Vajhøj wrote:
>> On 7/23/2012 4:35 PM, Eric Sosman wrote:
>>> On 7/23/2012 2:30 PM, bob smith wrote:
>>>> Is it really necessary to write @Override when you override or is this
>>>> just "a good thing"?
>>>
>>>      Two benefits of @Override appear to me, one from its presence
>>> and one from its absence:
>>>
>>>      - If you write @Override and then misspell the method name or
>>>        mess up the parameter list, Java will say "Hey, wait: There's
>>>        nothing in the superclass with this signature; what do you
>>>        think you're doing?"  And then you'll say "Oops!" and fix
>>>        the problem, instead of wondering why your "overriding" method
>>>        doesn't seem to work.
>>>
>>>      - If you write a method and your IDE starts suggesting that you
>>>        ought to tag it with @Override, you'll be alerted that you've
>>>        overridden something you didn't intend to.[*]
>>>
>>>      Two benefits; that's all I see.  Hence, like indentation and
>>> Javadoc comments, not "really necessary" ...
>>
>> I see the biggest benefits being the documentation.
>>
>> It can be important to know that ones method may be called
>> by the super class.
>>
>> And all arguments seems related to extends not implements, so
>> I m not convinced that extending it to interface methods was
>> wise.
>
>     A separate @Implements annotation instead of @Override might
> have been better for interfaces.  But what should one do about
> abstract methods in abstract superclasses?  Are those @Override
> or @Implements, or maybe @Concretizes?  And why should the class
> with the actual implementation care about the distinction?  And
> what about concrete methods *intended* to be overridden, as in
> MouseAdapter?  @ProFormaOverrides?
>
>      Looks like fodder for a "whichness of the why" debate.

I think abstract methods should be treated like other methods in
classes.

The abstract class could later introduce an implementation.

We know that the interface will never.

Arne

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web