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

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]