Re: Methods supporting both package and OOP style calls

I have a stupid question - Why on earth do you want to do this? You're just complicating your code for, what seems to me, minimal benefit.

That said, if you want to use procedural calls, invest in looking at Exporter. Learn that magic, then assume that if it's a procedural call, there is no $self. If it's an OO call, there is a bless'ed $self. There is no package-call.

(Package calls are bad, anyways, due to the fact that you're hard-coding stuff. Very NOT-scalable.)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Re: Methods supporting both package and OOP style calls

Replies are listed 'Best First'.
Re: Re: Methods supporting both package and OOP style calls by jk2addict (Chaplain) on Aug 06, 2002 at 03:45 UTC
Like I said... " Yes, I know there are probably no good reasons to do this, other than some people like to use OOP, and some don't. I figure why not impliment both styles and let end users decide, and learn something new along the way. " All that aside, I have run into situations where 90% of the time, I'm using a class as a whole to do related work in that class, while the class keeps it's own private state information. But sometimes, I just want to call one of the classes methods outright to get work done, even multiple times without having to create an object or have that object keep internal state that will never get used. Take the DBI modules' `quote()` for example. Most of the time, I will have a $dbh object sitting around in which to call the `$dbh->quote()` method. But what if I'm just interested in using `DBI::quote()` directly on some string data without having to create a new `$dbh` object and all the possible overhead that comes with creating and object class/instance I will never use? Sure, I can create 2 seperate methods, that both call a 3rd private method, but than I've got two methods that do the same thing. It would seem better to have a single method do the right thing in either situation. Update I use Exporter all the time. The problem still comes down to how do you tell that it's a procedural call (thanks, that was the word I was looking for!) or a blessed ref OOP call? What do you test the first arg against? `ref(shift)` could be a multitude of things, some OOP related, some not OOP related, or I'm missing something. Update Redux File::Spec has a good solution I think. File::Spec used OOP style calls, while you can use the procedural methods in File::Spec::Functions -=Chris	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Methods supporting both package and OOP style calls
by jk2addict (Chaplain) on Aug 06, 2002 at 03:45 UTC

Like I said... " Yes, I know there are probably no good reasons to do this, other than some people like to use OOP, and some don't. I figure why not impliment both styles and let end users decide, and learn something new along the way. "

All that aside, I have run into situations where 90% of the time, I'm using a class as a whole to do related work in that class, while the class keeps it's own private state information. But sometimes, I just want to call one of the classes methods outright to get work done, even multiple times without having to create an object or have that object keep internal state that will never get used.

Take the DBI modules' quote() for example. Most of the time, I will have a $dbh object sitting around in which to call the $dbh->quote() method.

But what if I'm just interested in using DBI::quote() directly on some string data without having to create a new $dbh object and all the possible overhead that comes with creating and object class/instance I will never use?

Sure, I can create 2 seperate methods, that both call a 3rd private method, but than I've got two methods that do the same thing. It would seem better to have a single method do the right thing in either situation.

Update
I use Exporter all the time. The problem still comes down to how do you tell that it's a procedural call (thanks, that was the word I was looking for!) or a blessed ref OOP call?

What do you test the first arg against? ref(shift) could be a multitude of things, some OOP related, some not OOP related, or I'm missing something.

Update Redux
File::Spec has a good solution I think. File::Spec used OOP style calls, while you can use the procedural methods in File::Spec::Functions

-=Chris

[reply]
[d/l]
[select]