You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2009/04/23 13:40:55 UTC
[COMPRESS] COMPRESS-64 - enforcing correct sequence of API calls
I think it would be possible to enforce the correct sequence of API
calls in the AbstractxxStream classes.
This could be done as follows:
public finish(){
throw Exception if state is invalid
set state to finish
finish0();
}
// Override this if the sub-class needs to do anything.
protected finish0(){
}
Similarly for other methods. The Abstract class would be responsible
for maintaining the current state and checking that the method is
valid for the state.
Another way to do this would be to implement a checkValidState()
method that could be called by sub-classes. This would not enforce the
rules - subclasses would have to call it - but would allow the common
code to be extracted.
WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] COMPRESS-64 - enforcing correct sequence of API calls
Posted by Christian Grobmeier <gr...@gmail.com>.
> Well, it may involve a bit more work now - which I don't mind doing -
> but adding a new archiver should be easier, as it would not have to do
> the state checking.
>
> The idea is to have the re-usable code in the abstract super-class.
I completly understand your point. But does this bring so much
benefit? We check for two fields, I am not sure if this brings so much
benefit.
Additionally, if we do this, I would prefer to have:
doFinish instead of finish0 in the subclasses :-) That 0 looks so...
technical :-)
cheers,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] COMPRESS-64 - enforcing correct sequence of API calls
Posted by sebb <se...@gmail.com>.
On 23/04/2009, Christian Grobmeier <gr...@gmail.com> wrote:
> On Thu, Apr 23, 2009 at 1:49 PM, Torsten Curdt <tc...@apache.org> wrote:
> >> Similarly for other methods. The Abstract class would be responsible
> >> for maintaining the current state and checking that the method is
> >> valid for the state.
> >
> > Hm ... sounds a bit like overkill to me.
>
>
> for me too.. I had this discussion long time back with Torsten, cause
> the first drafts of compress had a similar approach. Meanwhile I share
> his opinion.
Well, it may involve a bit more work now - which I don't mind doing -
but adding a new archiver should be easier, as it would not have to do
the state checking.
The idea is to have the re-usable code in the abstract super-class.
> Cheers,
>
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] COMPRESS-64 - enforcing correct sequence of API calls
Posted by Christian Grobmeier <gr...@gmail.com>.
On Thu, Apr 23, 2009 at 1:49 PM, Torsten Curdt <tc...@apache.org> wrote:
>> Similarly for other methods. The Abstract class would be responsible
>> for maintaining the current state and checking that the method is
>> valid for the state.
>
> Hm ... sounds a bit like overkill to me.
for me too.. I had this discussion long time back with Torsten, cause
the first drafts of compress had a similar approach. Meanwhile I share
his opinion.
Cheers,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] COMPRESS-64 - enforcing correct sequence of API calls
Posted by Torsten Curdt <tc...@apache.org>.
> Similarly for other methods. The Abstract class would be responsible
> for maintaining the current state and checking that the method is
> valid for the state.
Hm ... sounds a bit like overkill to me.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org