The problem sounds more like a functional programming one (where you focus on evaluating "expression")than OOP one.
I don't think inheritance (though it might not what you really meant) it's necessarily good for customization and even less for flexibility. It leads to too tight a coupling.
OOP is a good way to deal with design time customization. At runtime, or so you could think, it's another story. Think about a calculator. It evaluates arbitrary expression at runtime. It all depends on how you model the problem and/or your spec.
As to how one might conceptualize overriding a sub, I might think of a sub a value in a hash with rules determining which key (and therefore sub) to pick, either at runtime or design time. Think about this (trivial) example:
sub make_binary { eval "sub { $_[0] }" }
my %op ;
$op{add} = make_binary '$_[0] + $_[1]' ;
$op{sub} = make_binary '$_[0] - $_[1]' ;
$op{mul} = make_binary '$_[0] * $_[1]' ;
$op{div} = make_binary '$_[0] / $_[1]' ;
$op{max} = make_binary '$_[0] > $_[1] ? $_[0] : $_[1]' ;
for (sort keys %op) {
print "2 $_ 3 = " . $op{$_}->(2,3) . "\n";
}
Kind of customization via "templating." | [reply]
[d/l] |
I'd explain in detail how you do this, but I'm walking out the door as I speak. Instead, take a look at the code for CGI::Kwiki and how they accomplish it. (Hint: Use a simple, global config file that contains what classes you should use.) | [reply] |
From your example, if I write a Forum::Format module, then all my code dealing with it looks like: my $ff=new Forum::Format;. If someone doesn't like part of it and wants to inherit and over ride that sub, say his new module is Forum::Format::NoHtml how does he tell my application that it should be using this New and Improved class/object instead of the regular old Forum::Format
Don't hard code the class name. Have a factory that gives you the appropriate formatter object based on a configuration file, environment variable, mod_perl setting or whatever.
Take a look at Class::Factory for one way of doing this.
| [reply] |