Re^2: object method question

> I can feel that you are a little bit confused. >

This exact sort of thing is a breeze in ruby.

I say that with good humor!

Unfortunately it's difficult to summarize precisely why I need to do what I'm trying to do here - the best I can do is explain _what_ I need...: It's important for me to be able to inject a custom method ( "dbq" ) into an object of an external class ( "DBI" ) which has been instantiated as an attribute ( "_dbh" ) of a custom base class ( "Foo" ). How do I do so?

That is what I would like to do - if possible.

>$db->dbq("whateverquery");

That's fine for client code that directly instantiates an object of the class in question ( "Foo.pm", "DB.pm", whatever ).

One may rightly ask: "So why not just pass the '$foo'/'$db' object itself to those legacy modules?"

Because the "$db"/"$foo" class is much, much more than a simple, specialized/dedicated piece of functionality, such as your example. Passing a large object with a bunch of unrelated methods/attributes to another object that simply wants access to one specific method is serious, ugly overkill which I'm hoping to avoid - the very sort of thing why it's all being refactored/rewritten in the first place. In other words, I'm trying to trick the old code into just using the new stuff without a care or any suspicion that something has changed.

I'm working with a semi-largish codebase, alot of which relies on receiving an object w/ a particular method, "dbq" in this instance. We're talking some 140+ perl scripts and shoddy modules that all rely on using/recieving this old '$dbh->dbq' thing.

I've done some major refactoring and have written some decent oop libraries to replace the existing mess with something more sane; however we simply don't have the time to re-write/re-factor every one of those 140+ scripts/modules at the moment.

Thanks for your time, it's difficult to communicate/discuss the nature of the problem without way too much verbosity and code!

Comment on Re^2: object method question Download Code

Replies are listed 'Best First'.
Re^3: object method question by aufflick (Deacon) on Oct 11, 2005 at 07:03 UTC
It's also a breeze in Perl, the other posters are simply questioning whether it is wise to go adding methods to a package that is outside your control. If you really want to do this, and you are smart about it (eg. your method only calls the publicly documented DBI methods on itself) then you simply need to define a new method in the right package space. For example, if you wanted to have a method that returned the most recent database error in all uppercase (to make sure it is heard loud and clear!), you could include this fragment in your code somewhere: `{ package DBI; sub err_loud { my $self = shift; return uc( $self->err() ); } }` [download] What the surrounding curly braces do is define a scopeso that the `package` pragma only applies within that scope. The sub/method err_loud thus becomes `DBI::err_loud` and will be found when perl tries to resolve the method call `$dbh->err_loud()` Perl trusts you not to shoot yourself in the foot, so you want to be really sure that this is what you want to do. As other posters have said, it would be more conventional to make a subclass.	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: object method question
by aufflick (Deacon) on Oct 11, 2005 at 07:03 UTC

If you really want to do this, and you are smart about it (eg. your method only calls the publicly documented DBI methods on itself) then you simply need to define a new method in the right package space.

For example, if you wanted to have a method that returned the most recent database error in all uppercase (to make sure it is heard loud and clear!), you could include this fragment in your code somewhere:

{
    package DBI;

    sub err_loud {
        my $self = shift;
        return uc( $self->err() );
    }
}
[download]

package

DBI::err_loud

$dbh->err_loud()

Perl trusts you not to shoot yourself in the foot, so you want to be really sure that this is what you want to do. As other posters have said, it would be more conventional to make a subclass.

[reply]
[d/l]