final methods and classes

[Mike Schilling]

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.

No, what I want is not to mslead customers as to what will work and
what won't. That frustrates them, which is a bad thing.

 

[Andreas Leitgeb]

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

And even if so, why do you (Leif, Mike, etc) feel obliged to prevent him
from shooting his toes off?

 

[Mike Schilling]

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 plain 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.


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

If I thought that "The docs tell you not to do that, therefore you
have no right to complain when it doesn't work" was effective, well, I
probably wouldn't have worked in software for thirty years. Actually,
I spent much of last week helping a customer who'd fouled up their
persistent storage by doing two things that we specifically document
as not supported. They're an important one, so saying "You made your
bed, now lie in it" was not an option.

 

[Rzeźnik]

Yes.

Not in my experience.

 

[Rzeźnik]

If I thought that "The docs tell you not to do that, therefore you
have no right to complain when it doesn't work" was effective, well, I
probably wouldn't have worked in software for thirty years.  Actually,
I spent much of last week helping a customer who'd fouled up their
persistent storage by doing two things that we specifically document
as not supported.  They're an important one, so saying "You made your
bed, now lie in it" was not an option.

You know the difference between development and support, right? By the
way, no one tells you to abandon your customer, you are not helping
him out of charity anyway. And as I said before - if you are writing
proprietary software it is easier for you to justify your opinions (do
not take it for granted though)

 

[Rzeźnik]

Because I'm a professional and I don't do shoddy work, and because I prefer
working with clearly defined APIs myself, so that's what I try to make.

That's deceptive to think that API is "clearer" because of extensive
use of finals, and if you believe that your work is less/more 'shoddy'
because of finals, you are lying to yourself.

 

[Mike Schilling]

You know the difference between development and support, right?

Yup. Development is my usual job, and support is what I do when my
boss tells me to. (Also what some of my co-workers do full-time, and I
like to make their job easier too.)

 

[Rzeźnik]

Rzeznik wrote:

Yup.  Development is my usual job, and support is what I do when my
boss tells me to. (Also what some of my co-workers do full-time, and I
like to make their job easier too.)

) Great one ) lol, I really like it

 

[Andreas Leitgeb]

But you are just guessing, and wrongly at that.

That can happen. "I guess that ..." makes the "..."-part quite weak, anyway.
I didn't say "I'm sure ...", afterall. I honestly (though as you clarified:
wrongly) thought so.

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 [...]

Wow! I'm gonna print that out and pin it up ... some day.

I even learnt two new (to me) words! To use one of them myself:
"The way you wrote that is a calumny, itself." Is that a correct use?
With "/ad hominem/ attack" did you refer to my "I guess ..." above, or
something else?

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.

Like aggregation? Yes, that was discussed and admitted to not always be
a solution, iirc.

I forgive you.

Phew!

 

[Mike Schilling]

I even learnt two new (to me) words! To use one of them myself:
"The way you wrote that is a calumny, itself." Is that a correct
use?
With "/ad hominem/ attack" did you refer to my "I guess ..." above,
or
something else?

After that, I hesitate to correct Lew [1], but he didn't use ad
hominem quite correctly. It's often used to mean "personal attack",
but actually it means disputing a proposition by attacking its
supporters instead of discussing the proposition itself. Like "Let
people extend classes even though that'll break the code? Right,
that's the kind of thing you'd expect from Andreas."

1. Not really. Lew's good about this kind of thing.

 

[Lew]

I even learnt two new (to me) words!  To use one of them myself:
"The way you wrote that is a calumny, itself."  Is that a correct
use?
With "/ad hominem/ attack" did you refer to my "I guess ..." above,
or
something else?

After that, I hesitate to correct Lew [1], but he didn't use ad
hominem quite correctly.  It's often used to mean "personal attack",
but actually it means disputing a proposition by attacking its
supporters instead of discussing the proposition itself.  Like "Let
people extend classes even though that'll break the code?  Right,
that's the kind of thing you'd expect from Andreas."

1. Not really.  Lew's good about this kind of thing.

The /ad hominem/ was the implication that the proponents of 'final'
classes would abandon customers in their hour of need, therefore their
argument was fallacious. This is an attack on the supporters rather
than a discussion of the proposition itself, combined with begging the
question (assuming that denying heritability would cause the customers
pain in the first place).

 

[Andreas Leitgeb]

[ explains the phrase /ad hominem/ attacks ]
Like "Let people extend classes even though that'll break the
code? Right, that's the kind of thing you'd expect from Andreas."

It's even the truth about me
I would warn them of dangling daggers, of course, in the docu.

I understand, that when faced with incompetent(*) users with big purses,
then other strategies may be favourable. For enough money I speak the
users' tongue, and if in their language non-final classes are "suggesting"
to be inherited without further look at the docu, then I'd have to translate
the API to their language.

*: (not docu reading, not even when already faced with problems)

 

[Andreas Leitgeb]

Marking a class final is no different from marking a method private rather
than public: both limit how the code can be used and both are used to
declare intent and impose design and structure

Indeed. And there've been times where I cursed the developers of
some API for making some particular method private. In some case
it was fortunately open source and I could just copy the class to
a different path, modify it to my needs and use mine rather than
the library's.

and limit the problem space for both the developer of the library
and for the developer of the client that uses the library.

The latter is happy about it, until they find their own problem
thereby limited away from the space of solveable problems.

Yes, sometimes these railings get in the way, Oh, yes.
but more often they keep people from tumbling over the edge.

Except that no real injuries happen in Java.
(Where they do, the programmers had better also look out for
stop signs painted to the ground in absence of railings)

 

[Rzeźnik]

Argumentum ad repetition?

Argumentum ad nauseam or argument from repetition. But not really.

I realise that is your view, but you haven't made

much in the way of an argument for it.

Because it is obvious. See, 'final' is a design decision and as such
can be questioned. If your design is questioned and your only argument
to support your decision is "it is just in case, you see, you tried to
use it and it incidentally broke" you cannot really say your design is
clean. Of course, you might have good rhetorics. As you can see it
depends on you and not on 'final'

Of _course_ an API with judicious use of "final" is clearer than one without:
not only _can_ you see that a given class isn't meant to be inherited from,
you _must_ see it.

I will see it but I may question that particular decision. Then it is
not really cleaner. Depends on how you present it.

Marking a class final is no different from marking a method private rather
than public: both limit how the code can be used and both are used to
declare intent and impose design and structure and limit the problem space
for both the developer of the library and for the developer of the client
that uses the library.

True. so ask yourself, do you support that mindset: Class should have
mostly private methods. That's how we limit client ability to tamper
with it in wrong ways.

 

[Mike Schilling]

I even learnt two new (to me) words! To use one of them myself:
"The way you wrote that is a calumny, itself." Is that a correct
use?
With "/ad hominem/ attack" did you refer to my "I guess ..."
above,
or
something else?

After that, I hesitate to correct Lew [1], but he didn't use ad
hominem quite correctly. It's often used to mean "personal attack",
but actually it means disputing a proposition by attacking its
supporters instead of discussing the proposition itself. Like "Let
people extend classes even though that'll break the code? Right,
that's the kind of thing you'd expect from Andreas."

1. Not really. Lew's good about this kind of thing.

The /ad hominem/ was the implication that the proponents of 'final'
classes would abandon customers in their hour of need, therefore
their
argument was fallacious. This is an attack on the supporters rather
than a discussion of the proposition itself, combined with begging
the
question (assuming that denying heritability would cause the
customers
pain in the first place).

OK. I took it as "It's bad because it would force you to abandon your
customers", but your reading works too.

 

[Lew]

Lew wrote :

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

And there's java.sql.Date which is suitable for dates at day resolution.

Out of curiosity, why are you linking to out-of-date Javadocs?

 

[Arne Vajhøj]

Lew wrote :


And there's java.sql.Date which is suitable for dates at day resolution.

Out of curiosity, why are you linking to out-of-date Javadocs?

Try Google on:
jdbc timestamp
and see what show up first.

Arne

 

[Dave Searles]

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.

[personal attack deleted]

Wrong.

(Some people just can't tolerate disagreement!)

 

[Dave Searles]

Tom Anderson wrote:
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.

[personal attack deleted]

Wrong.

 

[Arved Sandstrom]

Tom Anderson wrote:
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.

[personal attack deleted]

Wrong.

(Some people just can't tolerate disagreement!)

You're absolutely right - some people very clearly cannot.

AHS