The Override Problem

[Tim Tyler]

Tim Tyler wrote:
Tim Tyler wrote:
yes, but the discussion is more about the case when you make a mistake
and you don't override a method that you should actually override.

Some way of indicating methods that *must* be overriden in subclasses
may be an idea with some virtues.

That's what the abstract keyword does.[...]

...except that it doesn't work under some circumstances - thus my:
"unless you really need a base class implementation [...]" comment.

[...]

I can imagine it happening, though - for example if you need the base
class to continue to perform the default functionality - because you have
already released it to clients and don't want to change your interface.

You can imagine what happening? Please be more explicit.

Are you saying that you have a method in a base class that you suspect
may or may not have been overridden in third party code using your
library? Now the semantics of the base class have changed to where each
extension should supply its own overridden version? If you leave the
existing implementation won't the client code then essentially be broken
and they won't have gotten any message from the compiler or at runtime
concerning the incompatibility? Wouldn't it be better to make the
method abstract and force them to override by contract?

You've released the Base class - and it doesn't have abstract methods.

Later you discover that you want to be able to extend it in the way
under discussion. However, you can't change the methods to abstract
ones, becasue of third party code that depends on the existing
Base class interface.

You /could/ introduce a new PreBase class with abstract methods - and
extend it to produce the original Base class. However extended versions
of the PreBase class might again fail to work with the existing third
party code - which is expecting to get an instance of Base (or implicitly
a subclass thereof).

 

[Chris Smith]

the warning? With Eclipse you have the possibility to give an error. Of
course, you have to set it (default is 'ignore')

Yep. What I meant is that this only works if you get into the habit of
always adding @Override (or using Ctrl-Space auto-complete or other
methods of automating the overriding of methods, which will add the tag
for you). If typing a signature by hand, it's always possible to make
the two simultaneous mistakes of not adding the @Override tag *and*
misspelling the method name. If you had to add either of @Override or
@New, then that simultaneous error would be less probable, since you're
very unlikely to accidentally type @New *instead* of @Override.

I am not sure that's worth the bother; I was just saying it's not fool-
proof.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andrea Desole]

Yep. What I meant is that this only works if you get into the habit of
always adding @Override (or using Ctrl-Space auto-complete or other
methods of automating the overriding of methods, which will add the tag
for you). If typing a signature by hand, it's always possible to make
the two simultaneous mistakes of not adding the @Override tag *and*
misspelling the method name. If you had to add either of @Override or
@New, then that simultaneous error would be less probable, since you're
very unlikely to accidentally type @New *instead* of @Override.

I think I now understand. Yes, it can be a bit of work, but I see the point

 

[Thomas G. Marshall]

Andrea Desole coughed up:

Yes, I finally saw it. I was using an older Eclipse version, because
with newer versions I can't use the JBoss IDE. Now I finally saw it
on a 3.1 final

There's actually a /final/ now? I was figuring on a new ice age before
that!

Something like 3.1 M9837872288378827

....[rip]...

 

[Andrea Desole]

There's actually a /final/ now? I was figuring on a new ice age before
that!

Something like 3.1 M9837872288378827

no jokes, it's there

 

[Raymond DeCampo]

Tim Tyler wrote:


Tim Tyler wrote:

Andrea Desole <[email protected]> wrote or quoted:

yes, but the discussion is more about the case when you make a mistake
and you don't override a method that you should actually override.

Some way of indicating methods that *must* be overriden in subclasses
may be an idea with some virtues.

That's what the abstract keyword does.[...]

...except that it doesn't work under some circumstances - thus my:
"unless you really need a base class implementation [...]" comment.

[...]

I can imagine it happening, though - for example if you need the base
class to continue to perform the default functionality - because you have
already released it to clients and don't want to change your interface.

You can imagine what happening? Please be more explicit.

Are you saying that you have a method in a base class that you suspect
may or may not have been overridden in third party code using your
library? Now the semantics of the base class have changed to where each
extension should supply its own overridden version? If you leave the
existing implementation won't the client code then essentially be broken
and they won't have gotten any message from the compiler or at runtime
concerning the incompatibility? Wouldn't it be better to make the
method abstract and force them to override by contract?

You've released the Base class - and it doesn't have abstract methods.

Later you discover that you want to be able to extend it in the way
under discussion. However, you can't change the methods to abstract
ones, becasue of third party code that depends on the existing
Base class interface.

I addressed this in another post, but I'll repeat it here. The
assumption is that subclasses must override the method according to the
new semantics. Therefore, if you release a version of the base class
that doesn't mark the method abstract, there will be no indication from
the compiler or at runtime that the contract has been broken. The third
party's code will be broken, without any warning from the compiler, or
the runtime system. Wouldn't it be better to make the method abstract
and force the third party to fix their code?

You /could/ introduce a new PreBase class with abstract methods - and
extend it to produce the original Base class. However extended versions
of the PreBase class might again fail to work with the existing third
party code - which is expecting to get an instance of Base (or implicitly
a subclass thereof).

Ray

 

[Roedy Green]

at least a warning.
But wouldn't you find a not overriding method in B with the same name,
although with 'original', a bit misleading? Wouldn't it be better to
change B's method name? With modern tools you can do that easily

"Original" means the name is Supposed to be unique. It is not, it is
an error. It means I intended to write an original method, not
override some other.

Another way to deal with the problem is to have the IDE insert
comments when there is a base class other than object that methods are
either original or override based on what the actually do.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Tim Tyler]

[Case when an A.B.C. can't be used?]

I addressed this in another post, but I'll repeat it here. The
assumption is that subclasses must override the method according to the
new semantics. Therefore, if you release a version of the base class
that doesn't mark the method abstract, there will be no indication from
the compiler or at runtime that the contract has been broken.

Why has the contract been broken?

It's not clear which contract you mean - since all the method signatures
could easily remain the same under the circumstances I described.

The third party's code will be broken, without any warning from the
compiler, or the runtime system.

Why will the third party's code be broken? The point of the example
was to *avoid* breaking third party code.

Wouldn't it be better to make the method abstract
and force the third party to fix their code?

That /is/ a possibility. One might have to consult with the clients -
to see if getting them to rewrite their code is an acceptable solution.

 

[Raymond DeCampo]

[Case when an A.B.C. can't be used?]

I addressed this in another post, but I'll repeat it here. The
assumption is that subclasses must override the method according to the
new semantics. Therefore, if you release a version of the base class
that doesn't mark the method abstract, there will be no indication from
the compiler or at runtime that the contract has been broken.

Why has the contract been broken?

Because the new code requires that subclasses supply their own version
of the method. That was the whole point of the thing -- the semantics
of the base class changed requiring the subclasses supply their own
implementation of the method.


If you leave the old implementation of the method in the base class, the
compiler and/or runtime verification will not force the third party to
supply an implementation of the method, therefore the contract of the
superclass is broken.

It's not clear which contract you mean - since all the method signatures
could easily remain the same under the circumstances I described.

I'm referring to the new requirement of the base class that all
subclasses override the given method.

Why will the third party's code be broken? The point of the example
was to *avoid* breaking third party code.

No, the point of the example was to force the subclasses to override the
method.

That /is/ a possibility. One might have to consult with the clients -
to see if getting them to rewrite their code is an acceptable solution.

It is either that or it is broken. Our course, if I were your client
and you changed the semantics of a base class in such a way I probably
wouldn't be your client for very much longer. I imagine you agree.

Ray

 

[Thomas G. Marshall]

Raymond DeCampo coughed up:

Tim Tyler wrote:
....[rip]...

It's not clear which contract you mean - since all the method
signatures could easily remain the same under the circumstances I
described.

I'm referring to the new requirement of the base class that all
subclasses override the given method.

Yes, but part of the confusion between you two stems from such language.

I would rewrite your statement as this:

I'm referring to the new requirement /established by/
the base class that all subclasses /must/ override the
given method.

Because the statemtent as you gave it could be taken as something that the
base class must do. ("a requirement of the base class" != "a requirement
established by the base class").

 

[Raymond DeCampo]

Raymond DeCampo coughed up:

Tim Tyler wrote:

...[rip]...

It's not clear which contract you mean - since all the method
signatures could easily remain the same under the circumstances I
described.

I'm referring to the new requirement of the base class that all
subclasses override the given method.

Yes, but part of the confusion between you two stems from such language.

I would rewrite your statement as this:

I'm referring to the new requirement /established by/
the base class that all subclasses /must/ override the
given method.

Because the statemtent as you gave it could be taken as something that the
base class must do. ("a requirement of the base class" != "a requirement
established by the base class").

Thank you for the clarification.

Ray

 

[Tim Tyler]

Tim Tyler wrote:
Raymond DeCampo <[email protected]> wrote or quoted:

[Case when an A.B.C. can't be used?]

Are you saying that you have a method in a base class that you suspect
may or may not have been overridden in third party code using your
library? Now the semantics of the base class have changed to where each
extension should supply its own overridden version? If you leave the
existing implementation won't the client code then essentially be broken
and they won't have gotten any message from the compiler or at runtime
concerning the incompatibility? Wouldn't it be better to make the
method abstract and force them to override by contract?

You've released the Base class - and it doesn't have abstract methods.

Later you discover that you want to be able to extend it in the way
under discussion. However, you can't change the methods to abstract
ones, becasue of third party code that depends on the existing
Base class interface.

I addressed this in another post, but I'll repeat it here. The
assumption is that subclasses must override the method according to the
new semantics. Therefore, if you release a version of the base class
that doesn't mark the method abstract, there will be no indication from
the compiler or at runtime that the contract has been broken.

Why has the contract been broken?

Because the new code requires that subclasses supply their own version
of the method. That was the whole point of the thing -- the semantics
of the base class changed requiring the subclasses supply their own
implementation of the method.

If you leave the old implementation of the method in the base class, the
compiler and/or runtime verification will not force the third party to
supply an implementation of the method, therefore the contract of the
superclass is broken.

What if the original base class was final (and the new version is not)?

In the original version it won't have been possible for any subclasses to
exist in the first place - therefore you know that no third-party
subclasses will break when you update your code.

 

[Raymond DeCampo]

Tim Tyler wrote:

Raymond DeCampo <[email protected]> wrote or quoted:

[Case when an A.B.C. can't be used?]


Are you saying that you have a method in a base class that you suspect
may or may not have been overridden in third party code using your
library? Now the semantics of the base class have changed to where each
extension should supply its own overridden version? If you leave the
existing implementation won't the client code then essentially be broken
and they won't have gotten any message from the compiler or at runtime
concerning the incompatibility? Wouldn't it be better to make the
method abstract and force them to override by contract?

You've released the Base class - and it doesn't have abstract methods.

Later you discover that you want to be able to extend it in the way
under discussion. However, you can't change the methods to abstract
ones, becasue of third party code that depends on the existing
Base class interface.

I addressed this in another post, but I'll repeat it here. The
assumption is that subclasses must override the method according to the
new semantics. Therefore, if you release a version of the base class
that doesn't mark the method abstract, there will be no indication from
the compiler or at runtime that the contract has been broken.

Why has the contract been broken?

Because the new code requires that subclasses supply their own version
of the method. That was the whole point of the thing -- the semantics
of the base class changed requiring the subclasses supply their own
implementation of the method.

If you leave the old implementation of the method in the base class, the
compiler and/or runtime verification will not force the third party to
supply an implementation of the method, therefore the contract of the
superclass is broken.

What if the original base class was final (and the new version is not)?

In the original version it won't have been possible for any subclasses to
exist in the first place - therefore you know that no third-party
subclasses will break when you update your code.

I'm not sure I know what I would do in the above situation -- I hope I
would not find myself in it. I would probably advocate major
restructuring; it sounds like the base class changed so drastically that
it bears little resemblance to the original and perhaps should be a
different class.

I'm not sure what you are trying to gain with this discussion. I feel
that perhaps we have strayed from our original intentions.

In any case, I was participating in this thread to promote the use of
the "abstract" keyword as a means of forcing subclasses to provide an
implementation. I stand by that sentiment.

Ray

 

[Tim Tyler]

I'm not sure what you are trying to gain with this discussion.
I feel that perhaps we have strayed from our original intentions.

Maybe. You asked me to "please be more explicit." I was doing that.

However this looks like an appropriate point to bring things to a close.