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

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(@_);
}
[download]

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

Replies are listed 'Best First'.
Re: Re: Re: Methods supporting both package and OOP style calls by perrin (Chancellor) on Aug 07, 2002 at 04:17 UTC
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]
Re(4): Methods supporting both package and OOP style calls by mojotoad (Monsignor) on Aug 07, 2002 at 16:59 UTC
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]