[Rock-dev] Proposed solutions (so far) to the property settings pitfalls
Jakob Schwendner
jakob.schwendner at dfki.de
Mon Feb 7 18:51:56 CET 2011
On 02/07/2011 06:48 PM, Sylvain Joyeux wrote:
> The problem
> ===========
>
> task.config.value = 10
>
> does *not* change the field "value" of property "config" on the task.
> One has to do
>
> p = task.config
> p.value = 10
> task.config = p
>
> Proposed solutions
> ==================
> 0. make task.config.value = 10 transfer the updated property to the
> remote task
> 1. leaving it as it is
> 2. require people to use read/write (or get/set) methods to read and
> write the properties. For instance, it could look like
>
> p = task.read_config
> p.value = 10
> task.write_config(p)
>
> 3. make the returned values read-only and allow to provide a
> block to update
>
> task.config.value = 10 # will raise an exception
>
> # The following works
> p = task.config.dup
> p.value = 10
> task.config = p
>
> # and it is equivalent to
> task.config do |p|
> p.value = 10
> end # the property gets written at the end of the block
>
> Thoughts ?
>
>
> I personally don't like 0 as it involves having partial changes to the
> configuration data structures (which might be very bad if the component
> is currently running).
I like 3. Wouldn't mind 0 from an API point of view (most intuitive).
Dislike 2.
Jakob
More information about the Rock-dev
mailing list