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 '', @_);
    } 
  }
[download]

for those things not caught by $SIG{__(WARN|DIE)___} handlers.

Hugo