final methods and classes

[Mike Schilling]

But for a public API I'd be marking concrete classes as final unless
I
explicitly designed them for inheritance. And I can't think of too
many situations where I'd be doing this for concrete base classes as
opposed to abstract base classes.

That's where I wind up too.

 

[Tom Anderson]

Trails means badly-defined paths that go to obscure places and are
difficult to follow. As in 'The Java Tutorials [...] are organized into
"trails"'.

I disagree with the former, and with the implied insult to Sun's Java
Tutorial website.

You have no sense of humour, and are a dickhead.

tom

 

[Mike Schilling]

Trails means badly-defined paths that go to obscure places and are
difficult to follow. As in 'The Java Tutorials [...] are organized
into "trails"'.

I disagree with the former, and with the implied insult to Sun's
Java
Tutorial website.

You have no sense of humour, and are a dickhead.

I thought he had just made a joke.

 

[Andreas Leitgeb]

Being very careful about public and protected methods calling other public
and protected methods, so that overriding them selectively doesn't lead to
havoc.

I've never heard, that the act of overriding itself led to havoc, so I guess
it would depend on *how* they'd be overridden by someone. Then whose havoc
is it that is being led to? The API provider's or the one whose overrides
did it?

Maybe there is a cultural difference between people who feel more responsible
for what their customers might possibly do and other's who rather grant their
customers freedom and demand some reason.

Is it the same cultural difference that manifests in tags like: "Warning! does
not enable user to fly" on a superman costume?

 

[Rzeźnik]

I've never heard, that the act of overriding itself led to havoc, so I guess
it would depend on *how* they'd be overridden by someone.  Then whose havoc
is it that is being led to?  The API provider's or the one whose overrides
did it?

Unfortunately, it can. It does not matter who is stricken by havoc
You can read about it starting from:
http://en.wikipedia.org/wiki/Fragile_base_class

If you are theoretically inclined you may find 'Stata-Guttag groups'
interesting (I believe Szyperski in his 'Component software: beyond
object-oriented programming' has good description, but it's been a
long time since I last read his book)

Still, all these problems should not make you believe that inheritance
is devil's kin

Maybe there is a cultural difference between people who feel more responsible
for what their customers might possibly do and other's who rather grant their
customers freedom and demand some reason.

Is it the same cultural difference that manifests in tags like: "Warning! does
not enable user to fly" on a superman costume?

That's interesting interpretation indeed.
Another might be: it may have something to do with open-source vs
proprietary. If you rely on open-source software you are, I think,
inclined to experiment more with your libs - like trying wildest
inheritance patterns imaginable. Even if something went wrong, you can
always check the source and see why it went wrong, debug it
comfortably, fix a bug etc. Proprietary software users have to rely
mostly on docs and guidelines, so inheritance for them is asking for
troubles as it is quite hard to document that stuff properly (so they
cannot fully rely on vendor's docs) and it inflicts additional costs
to (so vendor might choose to mark things final mostly). Maybe that's
why they tend to perceive inheritance as something suspicious. But I
am just guessing.

 

[Mike Schilling]

I've never heard, that the act of overriding itself led to havoc, so
I guess it would depend on *how* they'd be overridden by someone.
Then whose havoc is it that is being led to? The API provider's or
the one whose overrides did it?

Do you really not know what I mean? Fine I'll be more explicit.

1. If A can't be subclassed successfully by reading its documentation,
but requires experimenting do determine how A was implemented, A
hasn't been designed to be subclassed.
2. If re-implementing A while adhering to its contract will break its
subclasses, A hasn't been designed to be subclassed..

Either way, A should be defined as final. Becasue the alternative is
that V2 of the library can break existing clients.

 

[Wojtek]

Lew wrote :

And the standard Java API does not have a class 'SqlDate'.

No, but there is the JDBC Timestamp,
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Timestamp.html which
extends Date.

 

[Rzeźnik]

Do you really not know what I mean?   Fine I'll be more explicit.

1. If A can't be subclassed successfully by reading its documentation,
but requires experimenting do determine how A was implemented, A
hasn't been designed to be subclassed.
2. If re-implementing A while adhering to its contract will break its
subclasses, A hasn't been designed to be subclassed..

Either way, A should be defined as final.

Here goes the single point of divergence between us.
I agree with your definition of 'not designed to be subclassed', but I
DO NOT agree with how you are proposing to deal with it.
If 1 occurs - well, someone's live may be easier still after he has
done 'experiments' and extended your class properly. Not comfortable,
encapsulation breaking, but nothing is perfect you know. Why take away
that chance?
If 2 occurs - you have a bug. If someone files a bug, well, go and fix
it or document better. If not, no one is subclassing, fine with you,
less work more time. But why take away the chance to improve your
design?

 Becasue the alternative is
that V2 of the library can break existing clients.

Which is not the end of the world (because it happens all the time),
which probably will be caught before shit hits the fan (if it is
important enough), which makes you think harder (because you are
inclined no to make people who rely on your software pissed off).

 

[Mike Schilling]

Here goes the single point of divergence between us.
I agree with your definition of 'not designed to be subclassed', but
I
DO NOT agree with how you are proposing to deal with it.
If 1 occurs - well, someone's live may be easier still after he has
done 'experiments' and extended your class properly. Not
comfortable,
encapsulation breaking, but nothing is perfect you know. Why take
away
that chance?

If they want to hack the class to make it subclassable, there are a
couple ways to do that. I can't prevent that nor do I want to, but
the fact that it nedded to be hacked acts as a warning that they need
to be careful when using a newer version.

If 2 occurs - you have a bug.

Not true; look up "fragile subclass". I'm not obligated to make code
work in ways it wasn't intended to be used.

Which is not the end of the world (because it happens all the time),
which probably will be caught before shit hits the fan (if it is
important enough), which makes you think harder (because you are
inclined no to make people who rely on your software pissed off).

I already thought hard enough to realize that the class can't be
subclassed safely. That's sufficient.

 

[Rzeźnik]

If they want to hack the class to make it subclassable, there are a
couple ways to do that.  I can't prevent that nor do I want to, but
the fact that it nedded to be hacked acts as a warning that they need
to be careful when using a newer version.

Yeah, right, so why this unfortunate 'final'?

Not true; look up "fragile subclass".  I'm not obligated to make code
work in ways it wasn't intended to be used.

I have referenced BFC myself a few times in this thread so no need for
looking it up. But anyway, so ok, you have even less problems. So why
this unfortunate 'final'?

I already thought hard enough to realize that the class can't be
subclassed safely.  That's sufficient.

You can't tell unless you deem yourself demigod there are cases
where this perfect knowledge is not required. Someone mentioned
security stuff, I mentioned tricks with equals method, immutability.
Let's sum it up: final may be safely used if you are sure that system
will not be working properly without it, not if you SUPPOSE that it
won't.

 

[Rzeźnik]

To signal that subclassing isn't supported.

We are going in circles. I could answer: how do you know? one more
time, and then point you to parts of my previous posts. So, to cut
long story short: use it with care, not just to be safe. It's not a
condom )

 

[Mike Schilling]

We are going in circles. I could answer: how do you know? one more
time,

I'm the author. It's not supported unless I say so

 

[Rzeźnik]

I'm the author.  It's not supported unless I say so

Blah, blah ))))

 

[Alessio Stalla]

Documentation is sufficient to "signal". final is stronger: it
prohibits.

BTW, final - when used for fields - is a purely compile-time concept:
once the class is compiled, nothing in the JVM prevents altering the
value of the field (for example System.out is final, but then you have
System.setOut()...). Is this true for 'final' classes, too?

 

[Andreas Leitgeb]

... I'm not obligated to make code work in ways it wasn't
intended to be used.

Customers sometimes have needs that no developer thought of
(or those who did, just want too much money for it).
Customers are often happy to bend some near solution to their
exact needs.
They don't really expect the vendor to care, so the vendor isn't
obliged to do anything special for them. If it breaks on
library-upgrade, they'll simply continue using V1.

If, however, V1 is written to make it extra hard to bend it
to their needs, then they'll look for a V1 from another vendor.

Some (non-software) appliances can easily be screwed open, and
modified inside despite warnings not to open them. Others are
glued close, and can only be pried open. Guess what one buys if
he expects to need some customizations...

The website "thereifixedit.com" is full of examples of things not
used in ways predicted by the vendors of each (mis-)used thing.
I don't claim that those solutions are good, but they are usually
the optimum of solutions reachable under certain conditions
(probably mostly of financial nature: a proper solution would
have cost much more).

Now, I guess that Lew, Mike and others will strongly point out,
that they don't want such customers, anyway, and there's nothing
I could (or would be willing to) say to change their mind on that.

 

[Rzeźnik]

Is this true for 'final' classes, too?

No, Java verifier checks whether class subclasses final class during
code loading and is required to throw VerifyError if it does.

 

[Rzeźnik]

To the typical software developer? Not in my experience.

Who is a typical software developer? Someone who does not read docs?

 

[Andreas Leitgeb]

Do you really not know what I mean? Fine I'll be more explicit.

I do think I did understand you, but I think you see it too narrow.
Whatever you said about non-documented (by experimentation) uses of
a particular API apply to plaiń use as well as to subclassing.

In any way it's not the vendor's "duty"/obligation to do anything
more than place a note in the doc warning against subclassing some
class, to be free to change undocumented features, later, at will.

Either way, A should be defined as final. Becasue the alternative is
that V2 of the library can break existing clients.

But only those who "deserve" it, for not following the docs, and quite
likely not even all of them.

 

[Lew]

Now, I guess that Lew, Mike and others will strongly point out,
that they don't want such customers, anyway, and there's nothing
I could (or would be willing to) say to change their mind on that.

But you are just guessing, and wrongly at that.

You asserted that declaring classes 'final' would lose customers, a
poorly-supported conclusion, and then based on your own
unsubstantiated conclusion guessed that I and others would reject such
customers, without even an attempt to tie such a guess to reason or
evidence, and as if such a decision were the only possible response to
such a situation, which of course it isn't even should such a
situation pertain.

Then after using that mish-mosh of poor logic, lack of evidence and
rhetorical obfuscation, you then engage in an /ad hominem/ attack on
the even further outrageously claimed intransigence of the parties.

Fallacies piled on calumnies based on ludicrous claims, all to no good
end. Your guess and the nonsense that went into it hardly seem worth
the effort to compose, much less expose to the readers of this forum.

I assert that properly-designed libraries will neither push customers
into the quandary you so speciously proposed, nor cause them to depart
as customers, nor that Mike or I would push those customers away in
the face of their complaints should such a situation ever occur.
Furthermore, the disadvantages you purport to inhere from our design
decisions are obviated by perfectly simple and explicable alternatives
for implementation that have been extensively discussed in this
thread. Your argument is unsubstantiated, unsound and in fact rather
insulting.

I forgive you.

 

[Mike Schilling]

Who is a typical software developer? Someone who does not read docs?

Yes.