On 24 November 2015 at 02:16, Paul Benedict <pbenedict_at_apache.org> wrote:
> I want to repeat a question I earlier sent:
> So what is the use case for the getters? Any examples? Because whoever is
> in charge of constructing of the PushBuilder has already determined and
> intended what is being pushed. I don't see why a builder needs to be
> queried for what's just been set.
>
I don't have any concrete examples, however I can image a framework that
might pass a pushbuilder to several concerns, each to push their associated
resources.
Obviously it can be usable without getters, but then I see little harm in
providing them and some use (see below):
> Also, after push(), it is documented that certain values will be cleared
> -- like path, etag, and lastModified. So I have some questions for the EG
> to ponder:
> 1) Should there be a boolean that represents if the builder is "clean" for
> a new build? A push would clean the builder.
> 2) Being reusable, should there be a count of how many pushes a builder
> performs?
>
Both of these points are rather contrary to your "whoever is in charge
already knows" meme above:)
The only field that is mandatory before a call to push is path(String), so
an isClean() method is essentially equivalent to getPath()==null , so the
state is already available. Note also that the javadoc says that push()
will throw an ISE if the path is currently null,
So I think the getters do provide adequate access to the state of the
builder and the statefulness is described in the current javadoc.
cheers
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com