(This discussion could perhaps be moved to its own thread, but for now I will continue here)
I feel the same way as Sandro regarding making Pivot classes easily extendible unless there is a good reason not to. Classes that are not meant to be extended should be marked as 'final' to signal the intent clearly, especially when there are limited Javadocs. Leaving classes non-final makes the API look unfinished IMO as there are times when the only things you would ever need in a subclass are the things marked private and therefore inaccessible to you. It would only need a few lines of documentation in the FAQ and Javadocs to explain that Pivot has chosen to allow its classes to be more easily extended rather than defaulting to making all methods & fields private. This could include a note to say that the API is still evolving and there may be changes later that could affect custom subclasses of Pivot classes, but the choice was made to help Pivot consumers get the most benefit out of the code in the library. There are many Pivot classes that *can* be extended because they are non-final, but which are very hard to meaningfully extend because of the private fields & methods. I mentioned org.apache.pivot.util.MessageBus and org.apache.pivot.util.Resources on the Dev mailing list recently, but Component Skins are a problem too. They contain a lot of private fields & methods which means that it is often easier (or the only option) to copy an entire Skin class and make changes in the copy rather than trying to extend the original, especially if painting is involved. (Threads mentioned above) http://apache-pivot-developers.417237.n3.nabble.com/org-apache-pivot-util-MessageBus-td3151762.html http://apache-pivot-developers.417237.n3.nabble.com/Some-thoughts-on-org-apache-pivot-util-Resources-localization-td3156467.html If anyone else feels strongly about this (either 'for', or 'against' changes) then please let us know. If there is a desire for change, then it might happen, but I don't think it will happen unless it is requested. Chris On 7 August 2011 04:43, Sandro Martini <[email protected]> wrote: > Hi all, > if you have some real use case that require to change a little some Pivot > classes (even that could change a little its API) maybe a JIRA ticket for > our 2.1 release could be useful. > > My point of view is to enable users to extend Pivot where needed. > And Greg likes real use cases before changing anything in Pivot ... so write > them (and if possible put even a reference to this thread). > > Bye > > Il giorno 06/ago/2011 20:05, "Bill van Melle" <[email protected]> ha > scritto: >> I remember facing a similar question when I wanted to add an http >> timeout to GetQuery. These classes could be much more usefully >> extended if some of their important locals were marked protected >> instead of private. (Not that it's an easy decision to know when to >> do that when you're implementing the base class. Pivot seems to take >> the conservative approach of marking everything private for which >> Pivot does not itself have a subclass that wants access.) >> >> On Sat, Aug 6, 2011 at 6:49 AM, Thomas G. Schuessler <[email protected]> >> wrote: >>> I cannot access the connection since it is local to Query's execute >>> method. >>> The only ways I can think of to fix this, are: >>> 1. Copy the complete Query.execute, modify it in MyPostQuery, and not >>> call >>> the inherited method at all. >>> 2. Create my own abstract Query class and subclass that. >
