Why is almost everything in the API final
cognitionmission at gmail.com
Tue Sep 3 08:19:12 PDT 2013
Final methods more so take the control out of the hands of the many developers, and places it in the hands of the API designers.
If there is an issue, and demands are high - would we rather
A. Report the issue and wait for the original API designer's development process to acknowledge, repair, and release a fix?
B. Report the issue to begin the above process, and improvise a workable workaround that let's a developer continue on with their work?
I too observed the advantages of being able to do this in SWING countless times…
Just a thought…
On Sep 3, 2013, at 9:38 AM, Mario Torre <neugens at redhat.com> wrote:
> On Tue, 2013-09-03 at 08:34 +0200, Fabrizio Giudici wrote:
>> On Tue, 03 Sep 2013 07:16:06 +0200, Tom Eugelink <tbee at tbee.org> wrote:
>>> AFAIK there was never a framework that used final a lot, so time will
>>> tell if the choice was right. Swing and the JDK made it this far. But
>> The NetBeans Platform API does use final a lot for the same rationale
>> we're discussing now.
>>> I'm suspecting the choice may have been made motivated more from the
>>> perspective of the developers of the framework (a few people) and not as
>>> much from the users (many people).
>> That's true, but you're misusing the perspective. Many users would only
>> see some minor impact of extending a class, while the few developers would
>> see the accumulation of a huge number of problems because those minor
>> things are multiplied by the large number of users. It's precisely by
>> putting oneself in the perspective of the developers that 'final' makes
> I've designed quite a few APIs and have extended Swing in a number of
> very creative ways over the years. While the extensibility comes handy
> after the 10+ years old API doesn't do anymore the things you would
> like, you quickly realise it's really part of the problems in the first
> place, so I agree completely with Fabrizio here.
More information about the openjfx-dev