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

@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 the same request? If it's the case, wouldn't we need to add proper

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

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

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; public

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

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 reset

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

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: 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 the same request? If it's the case, wouldn't we need to add proper synchronization to the getStream method anyway? public synchronized