[ 
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091570#comment-17091570
 ] 

Geertjan Wielenga edited comment on NETBEANS-4222 at 4/24/20, 1:22 PM:
-----------------------------------------------------------------------

You were really planning to provide no motivation up front, no use cases, no 
API change discussion... really? Is that also how you do API changes for your 
own software?


was (Author: geertjanwielenga):
You were really planning to provide no motivation up front, no API change 
discussion... really? Is that also how you do API changes for your own software?

> 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

Reply via email to