Re: Procedural vs OOP modules

also note that you can have functions in an OOP module which do not need to know the state, do not need to take the object as input. In which case you just call them as you would without being packaged in an OOP module. That's equivalent of static functions in C++ and Java.

my $xx = XX->new();
$xx->oopfunc("abc");
XX::staticfunc("abc");

{# the OOP module XX
package XX;

sub new {
    my $class = shift;
    my $params = $_[1];

    my $parent = ( caller(1) )[3] || "N/A";
    my $whoami = ( caller(0) )[3];

    my $self = {
        'state' => 'xxx'
    };
    bless $self, $class;
    return $self
}

# call it as
# my $xx = XX->new();
# $xx->oopfunc(...);
sub oopfunc {
    my $self = shift;
    my $params = shift;
    print "i am using state: ".$self->{state}."\n";
}
# call it as XX::staticfunc(...);
sub staticfunc {
    my $params = shift;
    print "static func called.\n";
}
1
}
[download]

Comment on Re: Procedural vs OOP modules Download Code

Replies are listed 'Best First'.
Re^2: Procedural vs OOP modules (mixing interfaces) by LanX (Saint) on Oct 29, 2021 at 10:10 UTC
There are "class methods" like `Class->new()` which expect `$class` as first arg, but you propagate `Class::func()` which doesn't. I'm not thrilled about mixing `$obj->methods()` which expect `$self` and such pure functions `Class::funcs()` ... This has some code smell for me and should be well thought of. I think this might sabotage many patterns like sub-classing... Can you give an example where this makes sense? update I took a quick glimpse into static functions for C++ and Java and they look very much like class methods to me. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l] [select]
Re^3: Procedural vs OOP modules by bliako (Abbot) on Oct 29, 2021 at 11:29 UTC
`Can you give an example where this makes sense?` When one wants to use such functions without instantiating an object first. But I guess one can use class methods (as per your definition) and make sure to consume the 1st param which will be the classname. `I think this might sabotage many patterns like sub-classing...` You mean because `staticfunc` will not be seen in a sub-class unless you do both: `use base 'Class';` and `use Class;` ? I guess yes that's a problem. `I took a quick glimpse into static functions for C++ and Java and they look very much like class methods to me.` Yes, except that they don't mess with the parameters to provide a classname. Do you suggest that there is no use-case for `staticfunc()`, but instead convert it into a class method and consume the 1st param, in order to provide accessing it without instantiation first? OK, fine. But I think it is important to provide access to such methods which do not need the state and can be called without instantiating a dummy object first which will be of no use whatsoever. So I think what I posted is useful, but I can edit it to use class methods when this dialogue ends. bw, bliako	[reply] [d/l] [select]
Re^4: Procedural vs OOP modules (namespace::clean) by LanX (Saint) on Oct 29, 2021 at 14:03 UTC
> Do you suggest that there is no use-case for staticfunc(), No I ask for use-cases justifying to deviate from `Class->method()` as default. Anything goes in Perl, but I'd like to know why a pattern was applied. I remember the Moo(se) folks using namespace::clean to wipe out any subs which are not part of the class, because otherwise they could be called as instance methods via the ISA chain. A `Class->method()` OTOH is capable to handle that case by checking if the first parameter `$_[0]` was blessed. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l] [select]

update