Hi Robert,

On 22/11/12 18:25, Robert Klemme wrote:
> On Thu, Nov 22, 2012 at 8:17 AM, Garthy D
> <garthy_lmkltybr / entropicsoftware.com>  wrote:
>
>> What I don't like with the above is that whenever I set v, I have to be
>> careful to use "self.v =<value>", rather than "v =<value>" when I perform
>> assignment, because the latter will just create a local variable and not
>> call the "v=" method I've created. It's fine when called externally on the
>> object, but any internal writes need a "self." prefix. I'm not keen on
>> expecting the user to do this each time, when using "@v" equivalent is so
>> much easier to use.
>>
>> Is there a better way to implement this, such that the user can write code
>> similarly to the listing at the top? Is there some syntactic sugar I am
>> unaware of that can be used instead of "self.foo"? The goal is to make the
>> user API for this nice and simple- I don't mind if I have to mess about to
>> make it happen, and I've already got a custom "method_missing", and adding
>> code to that is no issue.
>
> The only solution for this that I can see is to use some kind of
> transaction: you open the transaction, store object state, work with
> the object and at the end something inspects instance variables and
> writes all changed values.  But frankly, OR mappers do exist for Ruby,
> ActiveRecord is just one of them.  So if it is OK to fill in "RDBMS"
> for "remote storage" then you could simply use that.  Other than that
> I'd stick with using the accessor.

Thanks for that.

I was hoping there might be a way to wrap the accessor-style solution in 
some way that I hadn't thought of, as this particular solution fits in 
elegantly with the rest of the code. If it was possible to hook instance 
variable (eg. @foo) writes and reads in some way I think I'd approach it 
that way- I just don't know if this is possible.

Having said that, I've been weighing up converting things to use a 
solution along the lines you mention, most likely through a whitelist or 
blacklist of variables to save in the current object, which I push 
across periodically (changes only). This is the less elegant solution 
from an architectural point-of-view (ie. it's a good solution, just a 
bit trickier to fit in with my existing code), but I'd bet it would be 
the easiest to use from a user point-of-view.

In the problem I am trying to solve, ease of use by the user trumps 
elegance of expression, so I'm thinking the second solution (ie. the one 
in line with your suggestion) might be the best way to go about it.

Cheers,
Garth