final methods and classes
in [Java Programming]
|
From: Andreas Leitgeb on 14 Oct 2009 13:18 Mike Schilling <mscottschilling(a)hotmail.com> wrote: > 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.
From: Lew on 14 Oct 2009 13:21 Andreas Leitgeb wrote: > 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. -- Lew
From: Mike Schilling on 14 Oct 2009 13:22 Rzeznik wrote: > On 14 Paz, 19:06, Leif Roar Moldskred > <le...(a)huldreheim.homelinux.org> > wrote: >> Alessio Stalla <alessiosta...(a)gmail.com> wrote: >>> Documentation is sufficient to "signal". >> >> To the typical software developer? Not in my experience. >> > > Who is a typical software developer? Someone who does not read docs? Yes.
From: Mike Schilling on 14 Oct 2009 13:23 Andreas Leitgeb wrote: > > 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.
From: Andreas Leitgeb on 14 Oct 2009 13:25
Rzeźnik <marcin.rzeznicki(a)gmail.com> wrote: > On 14 Paź, 19:06, Leif Roar Moldskred <le...(a)huldreheim.homelinux.org> > wrote: >> Alessio Stalla <alessiosta...(a)gmail.com> wrote: >> > Documentation is sufficient to "signal". >> To the typical software developer? Not in my experience. > 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? |