Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Perl OO: Need a concise way of representing operations on an object

by wanna_code_perl (Pilgrim)
on Nov 04, 2012 at 02:32 UTC ( #1002158=perlquestion: print w/replies, xml ) Need Help??
wanna_code_perl has asked for the wisdom of the Perl Monks concerning the following question:

I have a Perl OO problem in need of some brevity. Basically, I have three classes:

  1. Foo::Container : Holds a bunch of Foo::Record objects in a non-trivial organizational structure.
  2. Foo::Record : Individual records have no reference to their parent container.
  3. Foo::Transform : Each Transform object ($tr) is initialized with a series of custom transformations. $tr->transform($container) would then apply the custom transformations on the given Container, and would be called for many, many different Containers in its lifetime. This class will be extended via inheritance to support several different classes of transformations.

Container and Record are straightforward, and writing each transformation is relatively easy as well, but I'm struggling to come up with a concise Perl syntax to express each transformation. For example, I have something like this:

# Error checking omitted for brevity... package Foo::Transform; my %transformations = ( # TODO - What goes here? ); sub new { my ($proto, @xforms) = @_; my $class = ref($proto) || $proto; bless({ xforms => [ @xforms ] }, $class); } sub transform { my ($self, $container) = @_; for my $xform (@{$self->{xforms}}) { my $foo = get_foo(); my $bar = get_bar(); # TODO - Apply transformation named $xform # on $container, with $foo and $bar # available as well. } }

I could of course do something like:

my %transformations = ( 'xform1' => sub { my ($cont, $foo, $bar) = @_; ... } );

... and then call $transformations{$xform}->($cont,$foo,$bar) in transform(), but the very thing I'm trying to avoid is the needless duplication of that boilerplate in every transformation. Most transformations will just be one or two statements, but some will be rather more complex.

I would like to have $cont, $foo, and $bar automatically available in lexical scope of each transformation, but I don't know if that's possible without using eval EXPR (as opposed to BLOCK syntax), and if I do that I lose compile-time checks, not to mention syntax highlighting. :-)

If there's a better OO/Perl pattern I'm missing here, please let me know! This doesn't smell right.

Replies are listed 'Best First'.
Re: Perl OO: Need a concise way of representing operations on an object
by Athanasius (Chancellor) on Nov 04, 2012 at 03:41 UTC

    I think you can achieve what you’re looking for by using closures as follows:

    { my ($foo, $bar, $container); my %transformations = ( xform1 => sub { ... }, xform2 => sub { ... }, ); sub transform { (my $self, $container) = @_; for my $xform (@{$self->{xforms}}) { $foo = get_foo(); $bar = get_bar(); $transformations{$xform}->(); } } }

    Using this approach, the anonymous subroutines (closures) in %transformations have access to $foo, $bar, and $container without the need for the boilerplate code.

    Hope that helps,

    Athanasius <°(((><contra mundum

      Thank you for your reply. I see what you are trying to do, but I think your use of my in lexical scope around the package means ($foo, $bar, $container) are shared between all Transform objects. This will break thread safety.

      Those variables are associated with a specific call to the transform() method, which is what I tried to demonstrate with my sample code. They need to remain private to that call and its delegates, but, ideally, without all the repetitive code. (Keep in mind this example is simplified... there will be more going on like alternative traversals, building transforms on top of other transforms, and so forth.)

        ...($foo, $bar, $container) are shared between all Transform objects. This will break thread safety.

        No, it won’t.

        The variables are shared between Foo::Transform objects within a thread (which doesn’t matter in this case, as they’re explicitly re-initialised in sub transform before being used). But in Perl, whenever a new process or thread is created, the memory is cloned at the point of creation, and thereafter is (by default) not shared (unless this is done explicitly).

        For processes, see fork:

        File descriptors (and sometimes locks on those descriptors) are shared, while everything else is copied.

        For threads, see threads and threads::shared:

        By default, variables are private to each thread, and each newly created thread gets a private copy of each existing variable.

        Hope that helps,

        Athanasius <°(((><contra mundum

Re: Perl OO: Need a concise way of representing operations on an object
by rjt (Deacon) on Nov 04, 2012 at 10:25 UTC

    The trick here is to return a closure from a generator function. Below is a complete working example. However the salient bit is returning refs to $cont and $foo from the generator function, and dereferencing them in the caller to initialize or change them.

    package Foobar; sub _setup_xforms { my ($cont, $foo); return (\$cont, \$foo, { xform1 => sub { printf("Level %d,foo=%s\n", $cont, $foo); +}, }); }; sub transform { my ($self, $cont) = @_; my ($cont_ref, $foo_ref, $xforms) = _setup_xforms(); $$cont_ref //= $cont; # //= to convince you it's not still set for my $xform (values %$xforms) { $$foo_ref //= 0; # //= as above $xform->(); $$foo_ref++; $self->transform($cont + 1) if ($cont < 5); print "Level $cont done, foo=$$foo_ref\n"; } } sub new { bless({},'Foobar') } my $foo = new Foobar( id => 1 ); $foo->transform(0);

    This produces the following output:

    Level 0,foo=0 Level 1,foo=0 Level 2,foo=0 Level 3,foo=0 Level 4,foo=0 Level 5,foo=0 Level 5 done, foo=1 Level 4 done, foo=1 Level 3 done, foo=1 Level 2 done, foo=1 Level 1 done, foo=1 Level 0 done, foo=1

      This is exactly the solution I was looking for. It looks like it'll be easy to extend.

Re: Perl OO: Need a concise way of representing operations on an object
by Jenda (Abbot) on Nov 04, 2012 at 11:51 UTC

    The objects are irrelevant in this case.

    Maybe it'd be enough to local()ize the variables instead of insisting that they are lexical:

    { our ($cont, $foo, $bar); my %transformations = ( xxx => sub { use_the($foo,'and', $bar); as_you_need($cont); }, ... ); } ... for my $xform (@{$self->{xforms}}) { our ($cont, $foo, $bar); local $foo = get_foo(); local $bar = get_bar(); local $cont = $container; $transformations{$xform}->(); }

    I would not bother and just access $_[0], $_[1] and $_[2] within the transformations.

    The only other option is a source filter and I bet you don't want to go there.

    Enoch was right!
    Enjoy the last years of Rome.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1002158]
Approved by Athanasius
and the monastery is silent...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2018-06-25 05:21 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.