pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bartlett <cbartlet...@gmail.com>
Subject Re: Invoking an HTTP POST service that returns a value object, not a URL
Date Sun, 07 Aug 2011 10:06:36 GMT
(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)

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


On 7 August 2011 04:43, Sandro Martini <sandro.martini@gmail.com> 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" <bill.van.melle@gmail.com> 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 <tgs@arasoft.de>
>> 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.

View raw message