in reply to regex transforms of object attributes

If your class lends itself to the technique, you could use an lvalue method and avoid the need to copy anything.

#! perl -slw use strict; package Test; sub new{ my( $class, $value ) = @_; return bless { content => $value }, $class; } sub content : lvalue { my( $self ) = shift; $self->{ content }; } 1; package main; my $thing = Test->new( 'empty' ); print $thing->content; $thing->content = 'the quick brown fox'; print $thing->content; $thing->content =~ s[\b(.)][\U$1]g; print $thing->content; __END__ P:\test>368057 empty the quick brown fox The Quick Brown Fox

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

Replies are listed 'Best First'.
Re^2: regex transforms of object attributes
by ambrus (Abbot) on Jun 20, 2004 at 20:20 UTC

    BrowserUk, I see a contradiction between your post.

    In Re^2: regex transforms of object attributes, you say (rightly) that encoding a hash key string in the caller code breaks the encapsulation of the object. Using an lvalue method is, however, almost just as wrong. An lvalue method in Perl cannot do a check on what value you set, or do some computation with the rhs expression (in case the implementation of the attribute changes), so it is IMO not much better than just using a hash key. This is the weakness of the OO support of perl.

      Mostly, I agree with you as I recognised in this thread from a while back--but a couple of self-quotes from my posts in this thread:

      If your class lends itself to the technique, ...

      And

      Of course, if the content has to be verified then using an lvalue sub will also break, but that a different argument entirely:)

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

      They key difference is that an lvalue method uses a public interface and does not rely on implementation of the object. When choosing to have an lvalue method you choose to have a simple and limited interface, which you argue against, but you're not breaking encapsulation. So there are two different issues.

      ihb