Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > @Override

Reply
Thread Tools

@Override

 
 
Daniele Futtorovic
Guest
Posts: n/a
 
      07-23-2012
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.
 
Reply With Quote
 
 
 
 
Silvio Bierman
Guest
Posts: n/a
 
      07-23-2012
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..

 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-23-2012
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


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-23-2012
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


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      07-23-2012
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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-23-2012
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


 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      07-24-2012
On Mon, 23 Jul 2012 19:53:21 -0400, Arne Vajh°j <(E-Mail Removed)>
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
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      07-24-2012
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
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-24-2012
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


 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      07-24-2012
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
(E-Mail Removed)d
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments