[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091565#comment-17091565
]
Markus Sunela edited comment on NETBEANS-4222 at 4/24/20, 1:17 PM:
-------------------------------------------------------------------
Thanks for the comments and the book links. They're good read!
You have all the freedom and rights to not to accept the patch, and your
reasons are much more well thought and better founded than mine. Good API
design of course is hard and delicate work, and I am not qualified to argue
that and the long experience of you both working with NetBeans platform. What I
am putting forward is a suggestion.
Personally, I just don't see value in making and keeping API closed down just
because it is considered good design, when it severely limits the future
possibilities what could be achieved using and extending the classes that are
already there. Documenting the opened APIs is easy enough and no, I am not
proposing any changes without test coverage and or versioning. The pull request
was just an answer to Geertjan's idea to "make the changes yourself" - here are
the changes. Creating the tests, documentation and all would be wasted, if
there wouldn't be any interested in the changes.
In my opinion any specific use-cases are not that matters, when the problem is
overall API rigidity (which is, I guess, at least in part subjective notion),
but if you some use-cases, here's the acute one I am trying to solve: being
able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other.
was (Author: markus.sun...@fluidit.fi):
You have all the freedom and rights to not to accept the patch, and your
reasons are much more well thought and better founded than mine. Good API
design of course is hard and delicate work, and I am not qualified to argue
that and the long experience of you both working with NetBeans platform. What I
am putting forward is a suggestion.
Personally, I just don't see value in making and keeping API closed down just
because it is considered good design, when it severely limits the future
possibilities what could be achieved using and extending the classes that are
already there. Documenting the opened APIs is easy enough and no, I am not
proposing any changes without test coverage and or versioning. The pull request
was just an answer to Geertjan's idea to "make the changes yourself" - here are
the changes. Creating the tests, documentation and all would be wasted, if
there wouldn't be any interested in the changes.
In my opinion any specific use-cases are not that matters, when the problem is
overall API rigidity (which is, I guess, at least in part subjective notion),
but if you some use-cases, here's the acute one I am trying to solve: being
able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other.
> 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
