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
In reply to Re: Re: Methods supporting both package and OOP style calls
by jk2addict
in thread Methods supporting both package and OOP style calls
by jk2addict
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |