final methods and classes
in [Java Programming]
|
From: Mike Schilling on 14 Oct 2009 14:10 Rzeznik wrote: > On 14 Paz, 19:28, "Mike Schilling" <mscottschill...(a)hotmail.com> > wrote: >> Andreas Leitgeb wrote: >>> Mike Schilling <mscottschill...(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 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. >> >>>> 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. >> >> 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? 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.)
From: Rzeźnik on 14 Oct 2009 14:12 On 14 Paź, 20:10, "Mike Schilling" <mscottschill...(a)hotmail.com> wrote: > Rzeznik wrote: > > > 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.) :-)) Great one :-)) lol, I really like it :-)
From: Sherm Pendley on 14 Oct 2009 14:20 Rzeźnik <marcin.rzeznicki(a)gmail.com> writes: > Who is a typical software developer? Someone who does not read docs? Yes, unfortunately that is fairly typical. :-( sherm--
From: Sherm Pendley on 14 Oct 2009 14:21 Rzeźnik <marcin.rzeznicki(a)gmail.com> writes: > On 14 Paź, 19:22, "Mike Schilling" <mscottschill...(a)hotmail.com> > wrote: >> Rzeznik wrote: >> >> > Who is a typical software developer? Someone who does not read docs? >> >> Yes. > > Not in my experience. Count yourself lucky. sherm--
From: Andreas Leitgeb on 14 Oct 2009 14:53
Lew <lew(a)lewscanon.com> wrote: > Andreas Leitgeb wrote: >> Now, I guess that Lew, Mike and others will ... > 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! |