I'm sorry. I'm still not understanding what you're trying to achieve. Probably me being dim... it's been known to happen...
Can you give concrete examples of SomeClass and SomeOtherClass? What is the relationship between them? What are you trying to do? How are they used?
Just some real names would help :-)
What is the reason for SomeSub being a method of SomeOtherClass rather than SomeClass?
Without knowning more about what you're trying to achieve it's difficult to give more useful advice...
| [reply] |
Let me make this a lot simpler: Is there a way to let multiple packages (with subs named the same) share one $self? My below example shows how I'd like to use this whole mess (see comments in the code for further details):
eval {
my $foo = OurParentPackage->new;
$SIG{__WARN__} = sub { die @_ };
$foo->initialize;
$foo->run;
};
if ($@) {
print "content-type: text/html\n\n$@";
exit;
}
package OurParentPackage;
sub new {
bless { }, shift;
}
sub initialize {
my $self = shift;
require CGI;
$self->{CGI} = new CGI;
$self->{Config} = { 'this' => 'that' }; # config hash would be loa
+ded here.
# and some 'global' stuff....
$self->{script_build} = 1;
$self->{script_version} = '1.0 alpha';
return $self;
}
sub run {
my $self = shift;
if ($self->{CGI}->param('area') eq 'widgetone') {
if ($self->{CGI}->param('act') eq 'add') {
WidgetOne->add;
}
else {
WidgetOne->default;
}
}
elsif ($self->{CGI}->param('area') eq 'widgettwo') {
if ($self->{CGI}->param('act') eq 'add') {
WidgetTwo->add;
}
else {
WidgetTwo->default;
}
}
elsif ($self->{CGI}->param('area') eq 'widgetthree') {
# etc....
}
}
package WidgetOne;
sub default {
my $self = shift;
############
# the below line wont work because it needs the the above subs $se
+lf. I need to get its $self here somehow without re-running OurParent
+Package's initialize sub.
print $self->{CGI}->header;
############
}
sub add {
my $self = shift;
# code to add a 'WidgetOne' would go here.
}
package WidgetTwo;
sub default {
my $self = shift;
# the default 'WidgetTwo' page code would be here...
}
sub add {
my $self = shift;
# code to add a 'WidgetTwo' would go here.
}
package WidgetThree;
sub default {
my $self = shift;
# the default 'WidgetThree' page code would be here...
}
sub add {
my $self = shift;
# code to add a 'WidgetTwo' would go here.
}
| [reply]
[d/l]
[select] |
If you're trying to simplify access to the CGI object, sharing $self outside of a class hierarchy is an ugly way to do it. You're mixing objects and procedural code, for one thing, in a way that's going to confuse things for others (or perhaps for yourself, after time has passed).
When people read
sub somesub {
my $self = shift;
they expect that somesub is a legitimate object method, and not one that has been force-fed a reference to a class that is related only by way of common data members.
If you want to simplify access to a single CGI object, hide it behind a singleton or make it a global. Globals can be misused, but they have their places.
| [reply]
[d/l]
[select] |
Ah. I think I see what you're trying to do now. Let me re-state what I think it is, just in case I'm getting the wrong end of the stick.
- You have a family of widget objects that all have the same interface (new, initialise, run, default and add).
- new(), initialise(), and run() are common to all objects.
- What default() and add() do is dependent on the 'area' param of the CGI object.
- Whether run() calls default() or add() depends on the 'act' param of the CGI object.
I'm assuming that there is some reason that you have a separate initialise() method - perhaps you need to call it multiple times on the same object. If not, it might as well be called by new() at object creation time.
If the above outline is correct then some kind of state transition pattern would seem appropriate. There are several ways you could do this. Two that spring to mind are:
- You could store the different default/add subroutines in a hash $action based on the 'area' and 'act' parameters and make run() lookup the appropriate subroutine. This way you remove all the Widget* subclasses, which probably won't be what you want to do.
- You could dynamically change the state of the object to match the appropriate Widget class depending on the area parameter.
The latter method is very simple to implement. Indeed, if you change the parameter passed to 'area' to match the classname exactly (so it's "WidgetOne" rather than "widgetone" it becomes almost trivial.
sub run {
my $self = shift;
my $class = $self->{CGI}->param('area');
# We want to be careful that we're reblessing into a sensible cla
+ss
croak "$class not a subclass of OurParentPackage"
unless UNIVERSAL::isa($class, 'OurParentPackage');
bless $self, $class;
if ($self->{CGI}->param('act') eq 'add') {
$self->add;
} else {
$self->default;
}
}
package WidgetOne;
use base qw(OurParentPackage);
sub default { print "WidgetOne default\n" };
sub add { print "WidgetOne add\n" };
package WidgetTwo;
use base qw(OurParentPackage);
sub default { print "WidgetTwo default\n" };
sub add { print "WidgetTwo add\n" };
... and so on for the other Widget* classes ...
The above solves the problem quite neatly, and you can add new Widget* subclasses without touching run().
I still don't know the purpose of the Widget classes, so this advice may be wrong, but I would also seriously consider refactoring the CGI object outside the Widget class hierarchy. It looks a little like an MVC pattern waiting to happen.
Hope this helps.
| [reply]
[d/l] |
