wazoox has asked for the wisdom of the Perl Monks concerning the following question:

Dear Brothers,
I'm losing my Latin. I've made a fake example to illustrate my problem : I have a base class that define methods, and child classes that define the data returned thru package variables. However, it doesn't work as expected, I can't get any data back, probably because I'm missing some step ( guess what : I'm home and my "OO Perl" by TheDamian is at office today ). Here's the code from Parent.pm :

use strict; use warnings; package Parent; use Data::Dumper ; sub new { my $proto = shift ; return bless {}, $proto } sub show { my $self = shift ; my $proto = ref $self ; print $proto::data ; print Dumper $proto::data } 1;
And here's the code for Child.pm:
use strict; use warnings; package Child; use base 'Parent' ; our $data = { one => 1, two => 2 } ; 1;
Last, the script that uses Child.pm :
#!/usr/bin/perl use strict; use warnings; use Child ; my $obj = Child->new(); $obj->show();
This doesn't DWIM, $obj->show() returns nothing. It works of course if I move the show method to Child.pm, but I'd need to duplicate subs into all children, which is a sin. What magic am I missing ? Of course I could set up the data in a sub or a closure instead of a simple variable, but I'd like to understand what's happening anyway.

Replies are listed 'Best First'.
Re: displaying package variable from inherited method.
by Joost (Canon) on Jun 10, 2006 at 14:50 UTC
      ...Prints the variable $data in package "proto".

      Bummer... Of course ! shame on me... So there isn't any way around ? What do you think of this :

      Child.pm :
      use strict; use warnings; package Child; use Data::Dumper ; use base 'Parent' ; sub data { return { one => 1, two => 2 } }; 1;
      Then Parent.pm:
      use strict; use warnings; package Parent; use Data::Dumper ; sub new { my $proto = shift ; return bless {}, $proto } sub show { my $self = shift ; my $proto = ref $self ; print $proto->data(); print Dumper $proto->data() } 1;

      The script code remains of course unchanged. Unless I... May it be possible to get it working the way I meant by using tie ?

        In that example you're not actually sharing the data: you're creating a new hash every time data() is called. If you really want to share the data, you can do:

        my $data = { one => 1, two => 2 }; sub data { return $data; }

        I don't know how you'd use tie() to get the original code to work. If you really want that construct, you'll need to use symbolic references or - even more dangerous - eval.

        Also note that even if it would work as you expected, the original code will break as soon as someone subclasses Child.

        update: in the example you posted here, there's no need to do

        my $proto = ref $self; print $proto->data;
        You can just call
        print $self->data;
Re: displaying package variable from inherited method.
by adrianh (Chancellor) on Jun 10, 2006 at 14:52 UTC
    This doesn't DWIM, $obj->show() returns nothing. It works of course if I move the show method to Child.pm, but I'd need to duplicate subs into all children, which is a sin. What magic am I missing ?

    Your missing that the package var referenced by the method is $data in the package proto. You want something like:

    sub show { my $self = shift ; my $proto = ref $self ; my $val = eval "\$${proto}::data"; print $val; print Dumper $val }

    or, to avoid all that evil messing about with package global variables and associated hassles with the cases where you might want sub-classes of your children to inherit the same $data why not just do it like:

    { package Parent; use Data::Dumper ; sub new { my $proto = shift ; return bless {}, $proto } sub show { my $self = shift ; my $val = $self->data; print Dumper $val } } { package Child; use base 'Parent' ; sub data { return { one => 1, two => 2 } } }
      package Child;
      use base 'Parent' ;
      sub data { return { one => 1, two => 2 } }

      Yes, that's the way I've thought of (see my answer to Joost)... But perhaps I'll dig in the deeper mysteries of tie instead :)
      By the way there must be a name for what I'm trying to do, is it "object introspection"?

        By the way there must be a name for what I'm trying to do, is it "object introspection"?

        More like "breaking encapsulation".

        The whole point of classes and objects is polymorphism. That is, given an object, you don't care what its specific type is as long as it supports the operations you want to perform on it in a meaningful way.

        In your specific case, there's a perfectly good way to get that instance data without relying on package variables or symbolic references or even caring about the specific type of the class. That way is calling a method.

        With only a couple of classes, it might look like you're duplicating data by overriding methods. Maybe so... but it takes little imagination to see an expanded system with more subclasses, some of which can reuse their parent data (and good luck coding around that by accessing package variables symbolically!) and others that can override the parent method to call it and add, delete, or modify just one particular field in the results.

        You're making a lot more work for yourself trying to work against the object system. Embrace it!