[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