final methods and classes
in [Java Programming]
|
From: Alessio Stalla on 14 Oct 2009 12:54 On Oct 14, 6:23 pm, Rzeźnik <marcin.rzezni...(a)gmail.com> wrote: > On 14 Paź, 18:13, "Mike Schilling" <mscottschill...(a)hotmail.com> > wrote: > > > Rzeznik wrote: > > > On 14 Paz, 17:40, "Mike Schilling" <mscottschill...(a)hotmail.com> > > > wrote: > > > >> If they want to hack the class to make it subclassable, there are a > > >> couple ways to do that. I can't prevent that nor do I want to, but > > >> the fact that it nedded to be hacked acts as a warning that they > > >> need > > >> to be careful when using a newer version. > > > > Yeah, right, so why this unfortunate 'final'? > > > To signal that subclassing isn't supported. Documentation is sufficient to "signal". final is stronger: it prohibits. BTW, final - when used for fields - is a purely compile-time concept: once the class is compiled, nothing in the JVM prevents altering the value of the field (for example System.out is final, but then you have System.setOut()...). Is this true for 'final' classes, too?
From: Andreas Leitgeb on 14 Oct 2009 12:58 Mike Schilling <mscottschilling(a)hotmail.com> wrote: > ... I'm not obligated to make code work in ways it wasn't > intended to be used. Customers sometimes have needs that no developer thought of (or those who did, just want too much money for it). Customers are often happy to bend some near solution to their exact needs. They don't really expect the vendor to care, so the vendor isn't obliged to do anything special for them. If it breaks on library-upgrade, they'll simply continue using V1. If, however, V1 is written to make it extra hard to bend it to their needs, then they'll look for a V1 from another vendor. Some (non-software) appliances can easily be screwed open, and modified inside despite warnings not to open them. Others are glued close, and can only be pried open. Guess what one buys if he expects to need some customizations... The website "thereifixedit.com" is full of examples of things not used in ways predicted by the vendors of each (mis-)used thing. :-) I don't claim that those solutions are good, but they are usually the optimum of solutions reachable under certain conditions (probably mostly of financial nature: a proper solution would have cost much more). 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.
From: Leif Roar Moldskred on 14 Oct 2009 13:06 Alessio Stalla <alessiostalla(a)gmail.com> wrote: > Documentation is sufficient to "signal". To the typical software developer? Not in my experience. -- Leif Roar Moldskred
From: Rzeźnik on 14 Oct 2009 13:10 On 14 Paź, 18:54, Alessio Stalla <alessiosta...(a)gmail.com> wrote: > Is this true for 'final' classes, too? No, Java verifier checks whether class subclasses final class during code loading and is required to throw VerifyError if it does.
From: Rzeźnik on 14 Oct 2009 13:14
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? |