That is the correct answer, here is the longer version.
Sometimes it feels easier to hack a method to work both ways, but it is Bad(tm). You probably aren't using and data in self if you can call it with & without an instance. This means you should be doing
$answer = Package::foo($ob->member)
or
$answer = Package::foo('hibill')
If you are doing using something in $self if it is an object, and doing something slightly different if it is being called as a package function, then it isn't the same function. In this case put the common functionality in foo_common() and have two subs - one for instaces and one for class method - that do the slightly different things. This will make the code readable because people can tell they are different without having to know that soemthing in $self is used invisibly.
-jackdied | [reply]
[d/l] |
Please elaborate -- if the code works as OO code, what does it matter if it does something outside of what is normally OO?
Why is a superset of functionality not implementing the subset in "any meaningful way"?
I do agree that doing this sort of thing is asking for trouble and not a "clean" way of going about things; your statement struck me as dogmatic, however.
Matt
P.S. See Tracking Inheritance Directly due to Hybrid Methods and On Sinning and Subclassing Recalcitrant Modules for some details on my recent adventures with Time::Piece for more information on this very topic. All the trouble sources from having a constructor acting either procedurally or as a method; the problems could be avoided by isolating the procedural aspects:
sub constructor {
my $thing = shift;
my $class = ref $thing || $thing;
bless {}, $class;
}
sub factory_proc {
__PACKAGE__->constructor(@_);
}
| [reply]
[d/l] |
Why is something that can be called as a sub rather than a method not OO in any meaningful way? Subs are not attached to a data structure. Subs don't support inheritance. Subs don't support polymorphism (aka "late binding").
Perl being what it is, there are cheats to make a sub approximate these behaviors, but they are generally obfuscated and dangerous. If you want an object, use one. If you don't need any of that stuff, don't use OO.
Modules like CGI.pm give many people incorrect ideas about OO, i.e. that it's nothing more than a different syntax. If you look inside the code for that monster you see that CGI.pm only works at all by using a bunch of globals and assuming that only one CGI object will exist at a time. And ask Ovid how much fun it is to subclass.
| [reply] |
Why is something that can be called as a sub rather than a method not OO in any meaningful way? Subs are not attached to a data structure. Subs don't support inheritance. Subs don't support polymorphism (aka "late binding").
Yes, of course. I'm not confused on the definitions, differences, or their uses. I was just pointing out that in this case we clearly have an example of a sub/method "wearing both hats", possible only because of the flexibility of Perl. (as an aside, this convergence is far more likely with constructors, when you instantiate and bind your methods to a particular set of data, as opposed to just random methods -- such is the case with Time::Piece, where contruction happens either via new(), overloaded math operators, gmtime(), or localtime() -- this last two are procedural subs, but underneath they all use a constructor that does double duty as a method or sub: _mktime())
As I said, it's not a particularly good idea -- it just sounded like you were asserting that since there was a second hat involved, the first hat no longer applied. I apologize if that was not the intent of your statement.
Matt
| [reply]
[d/l]
[select] |