How about the following notion (supertype = any superclass and any
interface implemented by you or another supertype of yours):
*IF* your method overrides any non-abstract method in any
super*class*, you *MUST* specify @Override.
*IF* your method overrides no methods in any super*type*, you *MUST
NOT* specify @Override.
*IF* your method overrides only abstract methods from super*types*,
you *MAY* specify @Override.
(Theory behind this idea: You can add methods to classes without
breaking stuff. However, adding a method to an interface (or an
abstract method to an abstract class) breaks API and is therefore
rarely done; also, if it is done, the one making the change already
accepts breaking just about every implementation anyway, so any
accidental overriding methods by implementing classes becomes a moot
point). Solves Eric Winter's legitimate beef, no?
I'm not going to bother posting it to project coin, because it would
be a source-breaking change, and those don't qualify in the first
place. Though, I might use it as backup for the 'source' keyword
proposal, which I thought was a great idea but is being shot down by
just about everyone there except Howard Lovatt.
On Mar 16, 2:11 pm, Eric Winter <ejwin...@gmail.com> wrote:
> I like the @Override but it adds even more cruft when you want nice
> concise anonymous inner classes trying to fake closures... You would
> get the same problem if there was a bunch of required annotations.
> Perhaps another indicator that cleaner syntax for anonymous inner
> classes would be useful although falling short of the holy grail of
> true closures.
>
> On Mar 16, 7:12 am, Casper Bang <casper.b...@gmail.com> wrote:
>
> > > What do you mean "virtual by default"? Isn't every java method on a class
> > > that implements an interface "virtual"?
>
> > Yes unless declared final, hence virtual by default. You must
> > explicitly design a base class method NOT to be overridable.
>
> > > This is different from the question about whether the override keyword/
> > > annotation should be mandatory.
>
> > I know, but in languages where virtual is non-default/opt-in, the
> > problem of accedential override becomes somewhat more manageable,
> > especially in the existence of an override keyword like in C#.
> > Tulach's "Confessions of a Java Framework Arcitect" lays out some
> > horrific bytecode hacks in the NetBeans code base to remedy such
> > clashes.
>
> > /Casper
>
> > > Neil
>
> > > On Mar 15, 2:24 pm, Casper Bang <casper.b...@gmail.com> wrote:
>
> > > > Does ANY successor to Java use virtual by default? Not C#, nor Scala
> > > > nor Fan. How about JavaFX?
>
> > > > /Casper
>
> > > > On 14 Mar., 13:21, Marcelo Morales <marcelomorales.n...@gmail.com>
> > > > wrote:
>
> > > > > All right, my question has been answered. Thank you.
> > > > > Someone said it can be acomplished today. Anybody knows of something?.
> > > > > Now that I think about it, seems like a must for big projects like
> > > > > Netbeans.
>
> > > > > On Fri, Mar 13, 2009 at 7:39 PM, TorNorbye <tor.nor...@gmail.com>
> > > > > wrote:
>
> > > > > > ....and let me add that there may be better ways to accomplish this,
> > > > > > for example by requiring that all overrides must explicitly be
> > > > > > annotated with @Override and that any method overriding without one
> > > > > > is
> > > > > > an error...
>
> > > > > > On Mar 13, 4:30 pm, TorNorbye <tor.nor...@gmail.com> wrote:
> > > > > >> On Mar 13, 1:37 pm, "marcelomorales.n...@gmail.com"
>
> > > > > >> <marcelomorales.n...@gmail.com> wrote:
> > > > > >> > Arround min 36:10 - 38:00, there is a discussion on override
> > > > > >> > methods.
>
> > > > > >> > Non-overrideable is on the language today. isn't it?.
> > > > > >> > Listening to ep 234 seemed that they forgot final methods, the
> > > > > >> > 'final'
> > > > > >> > keyword. I am missing something?
>
> > > > > >> Yes - I'm the one who brought it up in that discussion, and what
> > > > > >> I'm
> > > > > >> talking about is not @NotOverridABLE, but @NotOverridING.
>
> > > > > >> In other words, let's say you have
>
> > > > > >> public class LibraryClass { // Some class in some cool library
>
> > > > > >> }
>
> > > > > >> public class Donkey extends LibraryClass {
> > > > > >> �...@new public void run() {
> > > > > >> }
>
> > > > > >> }
>
> > > > > >> Compile that, no problem.
>
> > > > > >> Now let's say you go and upgrade from version 1.0 of the library to
> > > > > >> version 1.1. What if the developer in version 1.1 had done this:
>
> > > > > >> public class LibraryClass implements Runnable { // Some class in
> > > > > >> some
> > > > > >> cool library
> > > > > >> public void run() {
> > > > > >> // Some important piece of functionality here that other
> > > > > >> parts
> > > > > >> of the class depend upon
> > > > > >> }
>
> > > > > >> }
>
> > > > > >> Now your method is accidentally overriding the run method. It
> > > > > >> wasn't
> > > > > >> intended to - when you wrote your subclass of the library class,
> > > > > >> this
> > > > > >> method wasn't present.
>
> > > > > >> With the @New (or @NotOverride etc) annotations the compiler would
> > > > > >> complain because it sees that your method which wasn't intended to
> > > > > >> override anything suddenly is.
>
> > > > > >> -- Tor
>
> > > > > --
> > > > > Marcelo Morales
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
