Oh, I see what you are complaining about now.

But I disagree that inheritance should generally be used to override how an object's members are stored. I don't advocate using get/set methods to access members when within the object's methods, unless you specifically designed those members to be overridden. But I agree with your point that if you've made that decision, then using the current implementation of :lvalue subs might be something to avoid.

I'd also avoid updating the RDMS for every single attribute assignment, caching the attributes in a hash and then flushing to the DB at destruction time, when requested, and/or at designed-in synchronization points.

Using a tied reference (like merlyn suggests) crossed my mind but it seem like a pretty big hammer to use (quite a bit of overhead and coding required).

An alternate work-around is:

my %TempMap;

sub foo :lvalue {
    my $self= shift;
    my $value= $self->fetch("foo");
    $TempMap{"".\$value}= [$self,"foo"];
    return bless My::Module::Value, \$value;
}

sub My::Module::Value::DESTROY {
    my $svValue= shift;
    my( $self, $name )= @{ $TempMap{$svValue} };
    $self->store( $name, $$svValue );
}
[download]

Which gets me to wondering how inheritance of :lvalue methods could be improved to avoid using tie to separate the code for fetching from storing (because I'd really like to provide a :lvalue interface to my members).

        - tye (but my friends call me "Tye")