I agree that a framework has to protect backward compatibilty by using final extensively, as you do. A final class can be turned into "not final" without problems for existing code. Without a foreseeable reason, you usually start with final classes and then you change your decision after the actual requirements of framework extenders emerge. Protect your API, "@deprecate" is far more difficult to manage.
Kent Tong wrote: > > > igor.vaynberg wrote: >> >> your perception of our convention is wrong. the things we make final >> by default are the things we do not expect to be overridden/subclassed >> by our users. >> >> -igor >> > > I seems what you said is different from the wicket FAQ (quoted below). For > a given > class or method, there can be only three decisions regarding its > extensibility: > 1) it's known that it needs extensibility. > 2) it's known that it doesn't need extensibility. > 3) it's unknown whether it needs extensibility. > > The FAQ says that it will be made final for 2) and and 3), but what you > said > is that it will be made final only for 2). > > > >> Why are so many classes and methods in Wicket final? >> >> Classes and methods in Wicket are generally declared as final until the >> need for >> extensibility is well understood. >> > -- View this message in context: http://www.nabble.com/anyone-disagree--tp14268271p14333911.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
