in reply to Re: OO Conversion Query - Sharing Data
in thread OO Conversion Query - Sharing Data

Hi again, please ignore the obvious errors such as 'undefined', I am at the very early stages of porting.

Reasoning

'igaro' doesn't really need OO porting as per say, the only reason I'm doing it is to make the code less fragile. I think.

Another reason is my relative lack of OO experience, and I have a tech interview on Tuesday. I'm bringing myself up to speed the hard way. :)

The code

In essence I'd coded so that one function = one file. It was rare for this to be anything different, which of course diminished the need for employing classes.

Now I'm converting the common functions, but the logic seems a little daft. Before I'd require the file and stick it into the namespace as 'igaro_xxx_xxx'. Now I'm instantiating the function into $self->{common}{xxx_xxx} and the other functions that used to call &igaro_xxx_xxx will have to do $self->{common}{xxx_xxx}->exec();

I have worked around the sharing of parent data by sending a reference to the parent through the params, like $self->{common}{xxx_xxx}->exec(parent=>$self);

Previously all the data was stored in several global hashes like %DATA.

My brain has just about fried itself.

  • Comment on Re^2: OO Conversion Query - Sharing Data

Replies are listed 'Best First'.
Re^3: OO Conversion Query - Sharing Data
by educated_foo (Vicar) on Apr 12, 2013 at 13:30 UTC
    $self->{common}{xxx_xxx}->exec(parent=>$self); Ew! It seems like you're trying to implement OO the C way in Perl. Writing an object system will teach you a lot about OO, but doing it in Perl results in some nasty code. You should look at bless for how to associate functions with an object in Perl. Basically, your global hash becomes $self, you bless it into a package, and you define your functions in that package. Then when you call them as $self->foo, $self gets passed as the first parameter.

    Then again, it seems like you already had a nicely modular system, so you may learn something from this exercise, but it won't help your code.

[reply]
[d/l]
[select]
      So just to confirm, I make a variable called our $igaro in the root igaro.pm module, then bless the instantiated parent into it.

      It does sound the way forward. If I'm right in saying the parent is never passed to the child (first parameter is a reference to the instantiation of that child) then I'd have to use a global variable.

      But if I use a global variable some of the lower pm modules will be always expecting the parent to be in a fixed variable name ($igaro), which seems a bad idea.

[reply]
        In brief: 
        $x = bless \%data, Igaro;
$x->foo(...); # calls Igaro::foo($x, ...)

        [download]
        Beyond that, I suggest reading perltoot and perlobj. The newer object docs are inferior (and, annoyingly, are replaced by stubs so the link shortcuts here aren't helpful).
[reply]
[d/l]
[reply]
      Wait a sec, bless, which I'm already using, doesn't solve the problem. To recap..

      parent calls child1 which returns something, which is stored on parent.

      parent calls child2 which needs data held on parent.

      ***

      The solutions thus far are;

      a) pass a reference to the parent when calling the child.

      Is there a simpler way to get at the parent?

[reply]
        Finally nailed it. I have another module that loads all the common functions (still one function per pm file), instantiating a copy into $parent, passing $parent when it does and then each common function saves the $parent value to $self.

        That should be the logical way to do it, since I'm passing $parent on each call. The only other way would be if I could use a command to get/call the parent from the child instantiations.

[reply]

In Section Seekers of Perl Wisdom