RE: toString shouldn't change the object's state

2006-11-02 Thread Jerome Louvel
Hi Vincent, Agreed, let's reuse the safer "getValue() : String" method introduced in StringRepresentation and deprecate toString(). Checked in SVN. Best regards, Jerome > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de Vincent > Envoyé : jeudi 2 novembre 2006 1

Re: toString shouldn't change the object's state

2006-11-03 Thread Vincent
Jerome, > Agreed, let's reuse the safer "getValue() : String" method introduced in > StringRepresentation and deprecate toString(). Thanks for making the change. Why not go one steo further and have getValue cache the value? private boolean cached = false; private value = null; publi

Re: toString shouldn't change the object's state

2006-11-03 Thread Piyush Purang
Is it an immutable that the getValue returns the same value for the entire lifetime of the object? else we have the added problem of invalidating the cached value etc... what is interesting about your example code is that you use a boolean and not a compare to null like private value = null;

Re: toString shouldn't change the object's state

2006-11-03 Thread Vincent
> Is it an immutable that the getValue returns the same value for the > entire lifetime of the object? I would tend to say 'yes'. > else we have the added problem of > invalidating the cached value etc... Sure, if we have a setValue method (or any method that affects the value), it should rese

Re: toString shouldn't change the object's state

2006-11-03 Thread Vincent
> The problem with cache invalidation for muttable objects in a > multithreaded environment isn't straightforward Why would two threads access the same request? If it's the case, wouldn't we need to add proper synchronization to the getStream method anyway? public synchronized InputStre

RE: toString shouldn't change the object's state

2006-11-05 Thread Jerome Louvel
2006 21:05 > À : discuss@restlet.tigris.org > Objet : Re: toString shouldn't change the object's state > > > > The problem with cache invalidation for muttable objects in a > > multithreaded environment isn't straightforward > > Why would two threads access

Re: toString shouldn't change the object's state

2006-11-05 Thread Vincent
Thanks Jerome. > 4) Caching is an important requirement that we will address later, probably > at a higher level (as a CacheFilter or CacheService?). There is a RFE for it > already: > http://restlet.tigris.org/issues/show_bug.cgi?id=25 Could you please shed some light on the threading question

RE: toString shouldn't change the object's state

2006-11-06 Thread Jerome Louvel
gt; De : news [mailto:[EMAIL PROTECTED] De la part de Vincent > Envoyé : dimanche 5 novembre 2006 19:32 > À : discuss@restlet.tigris.org > Objet : Re: toString shouldn't change the object's state > > Thanks Jerome. > > > > 4) Caching is an important requireme

Re: Re: toString shouldn't change the object's state

2006-11-03 Thread John D. Mitchell
On 11/3/06, Vincent <[EMAIL PROTECTED]> wrote: [...] private boolean cached = false; private value = null; private Object value = null; private RuntimeException rte = null; public String getValue() { if (!cached) { try

Re: Re: toString shouldn't change the object's state

2006-11-03 Thread Piyush Purang
The problem with cache invalidation for muttable objects in a multithreaded environment isn't straightforward .. I'll get back to you on the exception scenario...