in reply to Re^2: Module provides both of functional interface and object-oriented one
in thread Module provides both of functional interface and object-oriented one

The basic idea behind the code is: Foo->bar(@_) is really a nice way of saying Foo::bar("Foo", @_) and $f->bar(@_) is Foo::bar($f, @_). After that, ref $self returns false for the string "Foo" (as it is not a reference) but the class name for the object.

I don't think it's a bad approach at all, but it will break existing subroutine-using code unless you somehow sniff what type the first argument is.

Since your functional interface already requires passing a reference on every call, I don't actually see why anyone would prefer to use it. Personally, if your module is not in too wide use yet, I would choose to retire it and tell the people depending on your module to change their code.

Replies are listed 'Best First'.
Re^4: Module provides both of functional interface and object-oriented one
by anazawa (Scribe) on Feb 17, 2012 at 08:38 UTC
    I agree with you. According to your idea, users don't need to pass a reference subroutines on every call:
    use Blosxom::Header; # procedural interface my $value = Blosxom::Header->get($key); my $bool = Blosxom::Header->exists($key); Blosxom::Header->set($key => $value); Blosxom::Header->remove($key); # OO interface my $h = Blosxom::Header->new(); my $value = $h->get($key); my $bool = $h->exists($key); $h->set($key => $value); $h->remove($key);
    Nobody uses my module except for me :) But I belive this module should exist.

    Update:

    I noticed that it's not necessary to implement OO interface any more in this case.