[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091530#comment-17091530
]
Jaroslav Tulach commented on NETBEANS-4222:
-------------------------------------------
I tried to summarize the rationale in my [Practical API
Design|http://practical.apidesign.org/] book. There is even a story where a
colleague of mine wanted to make {{Node.getChildren()}} method overridable in
subclasses and why it is still {{final}}. In short: there has to be a balance
between freedom of API users and freedom of API maintainers. Btw. there is a
[freedom chapter in the 20 API Paradoxes e-book|http://buy.apidesign.org/].
Chapter 16 of the [Practical API Design|http://practical.apidesign.org/] book
contains a section _"Accepting API Patches"_. Reading it I can say that your
proposal removes our freedom because:
* Your patch restricts future evolution
* You have provided completely underdocumented patch
** the classes/methods you make public aren't document
** but worse: the overall use-case isn't explained
* You want to make API changes without any test coverage
* You API changes aren't versioned
I am not convinced it is enough justified to give up the NetBeans API evolution
freedom by accepting your changes at current state.
> Open up more of APIs in Node and PropertySheet
> ----------------------------------------------
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
> Reporter: Markus Sunela
> Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#000000}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
