Re: OO Conversion Query - Sharing Data

[educated_foo]

exactly why I'm not sure but I'm sure the grass is greener on the other side.

Here's your problem, unless its a "because the boss wants it" situation. If you're fine with it now, why shuffle the code to make it more fashionable? If you have problems with it now, what OO techniques will ameliorate them, and how?

[snoopy20]

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.

[educated_foo]

$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.

[Anonymous Monk]

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.

[Anonymous Monk]

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?