final methods and classes
in [Java Programming]
|
From: Rzeźnik on 14 Oct 2009 16:37 On 14 Paź, 21:23, Leif Roar Moldskred <le...(a)huldreheim.homelinux.org> wrote: > Rze??nik <marcin.rzezni...(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? 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.
From: Mike Schilling on 14 Oct 2009 18:40 Lew wrote: > 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). OK. I took it as "It's bad because it would force you to abandon your customers", but your reading works too.
From: Lew on 14 Oct 2009 20:28 Lew wrote : >> And the standard Java API does not have a class 'SqlDate'. Wojtek 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? -- Lew
From: Arne Vajhøj on 14 Oct 2009 20:42 Lew wrote: > Lew wrote : >>> And the standard Java API does not have a class 'SqlDate'. > > Wojtek 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? Try Google on: jdbc timestamp and see what show up first. Arne
From: Dave Searles on 14 Oct 2009 22:05
Tom Anderson wrote: > On Tue, 13 Oct 2009, Dave Searles wrote: >> 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!) |