thats why i said for internal API protection. public api shouldn't change, but i guess thats not always what we can guarantee
johan On 8/17/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > On 8/17/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > I think it is most of the time the responsibility of the developer > itself. > > If i want to override then i want to override > > > but if that method is not meant to be overridable then the chances are it > is > going to change in the next release and you have to rewrite your code. > this > might be ok for method where you call super and then add something, but > for > methods where you replace functionality it can be a headache. making > something overridable is pretty much a contract saying: the scope and > functionality of this method wont change. most people dont think about > that, > they just make it nonfinal by default and later change it at a whim. hell > some people make everything public.... > > -igor >
