Re: changing object's methods at runtime

Overriding one instance's methods at runtime is not directly possible, unless I'm mistaken (which is entirely possible and often even likely). What you could do is provide your own subclass of Apache::FakeRequest that overrides that method, and use that as the class of your object:

package Apache::FakeRequest::ViceRaid;
use base qw(Apache::FakeRequest);
sub lookup_uri {
  # do your stuff.
}
[download]

In your actual script, you'd use something like my $req=Apache::FakeRequest::ViceRaid->new() to instantiate your derived object.

The non-lvalue error means that you're assigning something to something else that cannot be assigned to. Things that you can assign to are lvalues, thus things that you can't assign to are non-lvalues. E.g.:

$ perl -e 'sub nonlvalue { return }; nonlvalue()=1;'
Can't modify non-lvalue subroutine call in scalar assignment at -e lin
+e 1, near "1;"
[download]

The nonlvalue subroutine is not an lvalue, so you get the error when you want to assign to it. perlsub has some information on how to make a subroutine return an lvalue.

CU
Robartes-

Comment on Re: changing object's methods at runtime Select or Download Code

Replies are listed 'Best First'.
Re^2: changing object's methods at runtime by adrianh (Chancellor) on May 21, 2003 at 20:19 UTC
Overriding one instance's methods at runtime is not directly possible, unless I'm mistaken (which is entirely possible and often even likely). While not the best solution in this instance (I'd subclass or go with Test::MockObject) it is possible to override methods at runtime - and it can occasionally be useful. See Micro Mocking: using local to help test subs for some examples.	[reply]
Re: Re: changing object's methods at runtime by bart (Canon) on May 22, 2003 at 02:25 UTC
Just create a subclass, that's what I'd do too. As for the custom method: provide an extra field in the original object (that is indeed the most dangerous aspect of it), and assign the sub ref to it. The method itself, as per robartes, needn't do anything other than fetching that sub ref and calling it. Now, looking at the source of Apache::FakeRequest, it looks like it is a blessed hash ref, with your named parameters as hash items. So you can just call new() with this additional named parameter, to have it inserted. `$req=Apache::FakeRequest::ViceRaid->new( method::lookup_uri => sub { # ... insert what you want it to do });` [download] That was easy. n.b. "`method::lookup_uri`" is still a bareword as far as Perl is concerned. I just used an outstanding value to reduce the risk of field name clashes. The source for the subclass can be pretty much as in robartes note. You just need to fill in the method call, which could look something like this: `sub lookup_uri { $_[0]->{method::lookup_uri}->(@_); }` [download] and now you have quite a generic subclass, all objects having their own custom method. You could generalize it, adding more methods, and calling SUPER::method if the necessary sub ref is missing. For example: `sub lookup_uri { ($_[0]->{method::lookup_uri} \|\| $_[0]->can(SUPER::lookup_uri))->(@ +_); }` [download] p.s. Caveat: I haven't tested this, as I don't have a mod_perl installation handy. Heh. Update: I have. It seems to work well. Who needs mod_perl for this kind of test, anyway? :)	[reply] [d/l] [select]