For what it's worth, I am a fan of polymorphic getter/setters, but I autogenerate them rather than writing them individually:
- if the field is immutable, the method knows it and generates an appropriate error message (but you can set key fields on newly created objects that don't yet have them set);
- they detect if the setting actually changes the value, and record the fact;
- when setting, derived values are invalidated;
- when getting, a not-yet derived value is calculated and cached;
- they are generated into an intermediate class, so the concrete class can override them simply (though overrides must call the SUPER:: method appropriately);
- they don't yet auto-generate documentation, but they could do so.
Nothing here that couldn't also be done with separate getters and setters; the two main benefits are the avoidance of code duplication, and the ease of iterating over the fields.
I agree with you about tie and lvalue though. :)
Update: I forgot the one time I have profitably used tie:
package MyApp::Log;
my $log;
sub enable { ...
$log = MyApp::Log->new($context);
tie *STDERR, 'MyApp::Log::STDERR';
... }
{
package MyApp::Log::STDERR;
sub TIEHANDLE {
my $class = shift;
bless {}, $class;
}
sub PRINT {
my $self = shift;
$log->die(join '', @_);
}
}
for those things not caught by
$SIG{__(WARN|DIE)___} handlers.
Hugo