final methods and classes
in [Java Programming]
|
From: Mike Schilling on 14 Oct 2009 15:02 Andreas Leitgeb wrote: > > 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.
From: Lew on 14 Oct 2009 15:17 On Oct 14, 3:02 pm, "Mike Schilling" <mscottschill...(a)hotmail.com> wrote: > Andreas Leitgeb wrote: > > > 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). -- Lew
From: Leif Roar Moldskred on 14 Oct 2009 15:23 Rze??nik <marcin.rzeznicki(a)gmail.com> wrote: > > 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. Argumentum ad repetition? I realise that is your view, but you haven't made much in the way of an argument for it. 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. 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. Yes, sometimes these railings get in the way, but more often they keep people from tumbling over the edge. -- Leif Roar Moldskred
From: Andreas Leitgeb on 14 Oct 2009 15:41 Mike Schilling <mscottschilling(a)hotmail.com> wrote: > [ 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)
From: Andreas Leitgeb on 14 Oct 2009 16:33
Leif Roar Moldskred <leifm(a)huldreheim.homelinux.org> wrote: > 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) |