@Override

Discussion in 'Java' started by bob smith, Jul 23, 2012.

  1. bob smith

    bob smith Guest

    Is it really necessary to write @Override when you override or is this just "a good thing"?
    bob smith, Jul 23, 2012
    #1
    1. Advertising

  2. 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.
    Daniele Futtorovic, Jul 23, 2012
    #2
    1. Advertising

  3. bob smith

    markspace Guest

    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."
    markspace, Jul 23, 2012
    #3
  4. In article <>,
    bob smith <> 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>
    John B. Matthews, Jul 23, 2012
    #4
  5. bob smith

    Lew Guest

    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
    Lew, Jul 23, 2012
    #5
  6. bob smith

    Eric Sosman Guest

    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
    d
    Eric Sosman, Jul 23, 2012
    #6
  7. bob smith

    Lew Guest

    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
    Lew, Jul 23, 2012
    #7
  8. On Mon, 23 Jul 2012 11:30:22 -0700 (PDT), bob smith
    <> wrote:

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


    In my Visual FoxPro classes, I ended up annotating each method
    with "base" or "overrides" to indicate whether the method was or was
    not defined in a parent.

    I have many classes that use parent class methods. I also have
    to override these from time to time. The annotations help me keep it
    all straight.

    I tend to be very strict on using such aids. If you want to be
    sloppy, you can do it, but do not think that you are doing yourself a
    favour.

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Jul 23, 2012
    #8
  9. 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.
    Daniele Futtorovic, Jul 23, 2012
    #9
  10. bob smith

    Lew Guest

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


    It is a lame patch for a language fault. Java SHOULD have required some
    "override" keyword anytime a method that has a definition in a base
    class is overridden in a derived class. Using an annotation is, as with
    almost all uses of annotations, a poor attempt at making up for the lack
    of a proper language feature.

    Yes, it is better to use @Override than to not use it. However, the
    compiler will only complain if you do use the annotation when you do not
    actually override anything. If you simply leave it out there will be no
    complaint.

    Backward compatibility makes it impossible to enforce an override
    keyword after the fact. Using an annotation as an afterthought is lame
    but better than nothing.

    Luckily, Scala has fixed this omission, amongst other things..
    Silvio Bierman, Jul 23, 2012
    #12
  13. bob smith

    Arne Vajhøj Guest

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

    >
    > It is a lame patch for a language fault. Java SHOULD have required some
    > "override" keyword anytime a method that has a definition in a base
    > class is overridden in a derived class. Using an annotation is, as with
    > almost all uses of annotations, a poor attempt at making up for the lack
    > of a proper language feature.
    >
    > Yes, it is better to use @Override than to not use it. However, the
    > compiler will only complain if you do use the annotation when you do not
    > actually override anything. If you simply leave it out there will be no
    > complaint.
    >
    > Backward compatibility makes it impossible to enforce an override
    > keyword after the fact. Using an annotation as an afterthought is lame
    > but better than nothing.


    True.

    But we are still waiting for the language that gets everything right.

    Arne
    Arne Vajhøj, Jul 24, 2012
    #13
  14. bob smith

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Jul 24, 2012
    #14
  15. bob smith

    Lew Guest

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

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Jul 24, 2012
    #16
  17. On Mon, 23 Jul 2012 19:53:21 -0400, Arne Vajhøj <>
    wrote:

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


    [snip]

    >> Backward compatibility makes it impossible to enforce an override
    >> keyword after the fact. Using an annotation as an afterthought is lame
    >> but better than nothing.

    >
    >True.
    >
    >But we are still waiting for the language that gets everything right.


    And it is a very good thing that we are not holding our breaths
    while doing so. Unless, of course, you REALLY like blue.

    And assuming we ever agree on "right". If we do, there will be
    one language only. Not likely. I prefer different languages for
    different things, sometimes for opposite reasons.

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Jul 24, 2012
    #17
  18. bob smith

    Eric Sosman Guest

    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
    d
    Eric Sosman, Jul 24, 2012
    #18
  19. bob smith

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Jul 24, 2012
    #19
  20. bob smith

    Eric Sosman Guest

    On 7/23/2012 10:57 PM, Arne Vajhøj wrote:
    > 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.


    Ah, but what about

    abstract class Super implements ActionListener {
    protected void helperMethod() { ... }
    ... // maybe an actionPerformed() here, maybe not
    }

    class NowWhat extends Super {
    @WhatAnnotationGoesHere // ?
    public void actionPerformed(ActionEvent evt) {
    ...
    }
    }

    In the NowWhat class, does actionPerformed() "implement" the
    method required by the ActionListener interface, or does it
    "concretize" the abstract actionPerformed() method of the Super
    class? Or does it "override" Super's concrete actionPerformed()
    method (not shown)? What if Super explicitly declares an abstract
    actionPerformed() method?

    More to the point, is the distinction useful? No, let's
    "concretize" that question: Can you suggest a scenario in which
    it would be helpful to distinguish among different flavors of
    overriding:

    - Implement a method of an interface the class `implements'

    - Implement a method of a superinterface of an interface
    the class `implements'

    - Implement a method of an interface an abstract superclass
    `implements' but leaves abstract

    - Implement a method explicitly declared as abstract by an
    abstract superclass

    - Replace a superclass' concrete implementation

    At the risk of dating myself (again), where's the beef?

    --
    Eric Sosman
    d
    Eric Sosman, Jul 24, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Guest
    Replies:
    2
    Views:
    543
    Natty Gur
    Jul 13, 2003
  2. Guest
    Replies:
    2
    Views:
    3,090
    Guest
    Jul 16, 2003
  3. Jon
    Replies:
    4
    Views:
    5,630
    Jonathan Williams
    Aug 7, 2003
  4. Gary Chamberlain

    Override the Encryption Key for Forms Auth

    Gary Chamberlain, Aug 27, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    315
    Gary Chamberlain
    Aug 27, 2003
  5. SStory
    Replies:
    3
    Views:
    2,409
    SStory
    Oct 30, 2003
Loading...

Share This Page