Re^4: Method of child module called by parent

Not the OP, but, Why is this backwards? This is actually a design pattern that I use somewhat regularly with Moose. Or the Correlary, Moose makes this design pattern extremely easy to implement with Delegation (and it's more advanced cousin Currying)

An example is my Build::VM library I'm working on: https://github.com/three18ti/Build-VM/blob/master/lib/Build/VM.pm

In my main class Build::VM, I have (stripped down):

package Build::VM;
use 5.010;
use Moose;
use strict;
use warnings;

use Build::VM::Guest;

has guest       => (
    isa         => 'Build::VM::Guest',
    lazy        => 1,
    default     => sub {
        Build::VM::Guest->new(
            name    => $_[0]->guest_name,
            memory  => $_[0]->to_kib($_[0]->guest_memory),
            disk_list   => $_[0]->disk_list,
            cdrom_list  => $_[0]->cdrom_list || [[]],
        );
    },
    handles    => {
        get_memory => 'memory',
    }, 
);
[download]

Then in my driver script that calls the module, I do:

#!/usr/bin/perl
use 5.010;
use strict;
use warnings;

use Build::VM;

# Get the parameters from the CLI or config file

my $bvm = Build::VM->new( 
    name => $name, 
    memory => $memory, 
    disk_list => $disk_list, 
    cdrom_list => $cdrom_list 
);

say $bvm->get_memory();
[download]

(ok, bad example because cdrom_list is the only one that is using delegation, technically ->memory is a method in the Build::VM::Guest object, it's just not a user defined function so it's a little more ambiguous).

Unless I'm misunderstanding what OP wants to do, why is this backwards or inside out? And if it's so backwards, why does Moose make it so easy? If you don't mind, what would be the appropriate organization for my various modules?

Also, when talking about Perl and inheritance, (which is what I think of when I hear "child class") I'm usually pointed to Moose Roles because they make multiple inheritance trivial (because it's not really inheritance, it's more like Ruby's mixins).

Thanks, I always like posts like this, even though it's not something I thought I was doing wrong, I like to learn when I am :)

-three18ti

Comment on Re^4: Method of child module called by parent Select or Download Code

Replies are listed 'Best First'.

Re^5: Method of child module called by parent
by Athanasius (Archbishop) on Jan 01, 2015 at 04:06 UTC

Hello three18ti, and happy New Year!

The OO design I described as back-to-front was a parent class calling methods defined in its own child class. By “parent” and “child” I meant two classes related by inheritance: the child class inherits the parent’s methods (and class data), and overrides method implementations only as needed. One of the main advantages of inheritance is that it facilitates code reuse: by creating a new class and having it inherit from an existing class, your new (child) class reuses as much as it needs of the code already written in the existing (parent) class. And there should be no need for the parent to access the specialised code in its child class(es). If the parent does reference its children, a maintenance problem is created: changes to one child class propagate upwards to the parent, and then potentially back downwards to sibling classes.

I had a look at your Build::VM project, and found this module structure:

+--Build-VM/
   +--lib/
   |  +--Build/
   |  |  +--VM.pm        (Build::VM)
   |  |  +--VM/
   |  |  |  +--Guest.pm  (Build::VM::Guest)
[download]

But this module layout does not constitute inheritance! The module Guest.pm begins:

package Build::VM::Guest;
use Moose;
use strict;
use warnings;
use MooseX::HasDefaults::RO;
[download]

There is no reference to any parent class, no extends statement, so no inheritance (or ISA) relationship is established. The module VM.pm contains:

use Build::VM::Guest;
[download]

which creates a HASA relationship, which is what I recommended to the OP when I said:

I suspect what you’re looking for is a helper class which your parent class accesses via a HASA or USES relationship.

Since your Build::VM and Build::VM::Guest classes are not related by inheritance, my comments about the design being back-to-front do not apply.

Note also that Moose delegation is not inheritance-related:

Delegation is a feature that lets you create "proxy" methods that do nothing more than call some other method on an attribute. This lets you simplify a complex set of "has-a" relationships and present a single unified API from one class.

Hope that helps,

Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

[reply]
[d/l]
[select]

Re^6: Method of child module called by parent

by three18ti (Monk) on Jan 02, 2015 at 16:49 UTC

Happy new year to you too!

Thanks for the explanation, that does help a lot! I see where I was confusing my terms now and why I misunderstood what you were saying.

[reply]