I just want to add my voice to this thread. I want to clarify that, first of all, I am not particularly referring to the HorizontalSplitPanel class but to the general practice of making methods and member variables private (or not making observers for private member variables) rather than protected in the GWT UI component classes and second that I use composition extensively and third that I come from a Swing background.
"... just simply take the HorizontalSplitPanel.java original class file form svn and remake it to your needs ?" If I wanted to maintain my own API, I would not be using somebody else's, would I? I want to use standard GWT components and, at the same time, I want to be able to subclass them to add some extra functionality when I need it. As mentioned, previously, branching our own code for a component is not the way to go, it is the best way to run into cross browser bugs and maintenance issues along the way. "Now, if you have a very specific use case that requires access to something with private visibility, there is a way to handle it. Javascript has no concept of visibility, so you can use a JSNI method to get around Java's private keyword." Right. Well, then why am I using GWT? Let's just implement the whole thing using Javascript and HTML. In my understanding, I should be able to use Java to implement my UI specially to do something as basic as extending the functionality of a component. Please, give us observers (accessor) so we do not need to hack the code using JSNI. "Now, if you have a very specific use case that requires access to something with private visibility, there is a way to handle it. Javascript has no concept of visibility, so you can use a JSNI method to get around Java's private keyword. By doing this, you acknowledge that you are accessing something that has no guarantee of actually being there in a future release (that's why it was private) but it'll allow you access where you really think you need it. " Come on, making a method/member "private" because it might not be there in future releases? Once you have an API, you cannot just restrict the visibility and hence restrict the use of it based on you future "maybe" needs. Fists of all, it is generally a good practice to think the API throughly before coding it so you do not have to redesign the whole thing once is published but even if you come up with a better way and something has to be changed, even a whole class, just deprecated the old way and give the new way of doing it instructions, we will be happy to make the changes. Now, do not take me wrong, of course there are things that should be private and of course stricter visibility is best but cut us, developers, some slack, we need to use the API, and sometimes even small changes are impossible due to lack of protected observers of private members or due to some methods being private instead of protected. Thank you for being ready to listen and thank you for making GWT. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
