Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^2: Module provides both of functional interface and object-oriented one

by anazawa (Beadle)
on Feb 17, 2012 at 06:20 UTC ( #954409=note: print w/ replies, xml ) Need Help??


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

Thanks for your suggestion. I think your code works correctly. Frankly speaking, I'm working on Blosxom::Header inspired by Plack::Util::headers. I'm trying to wrap existent subroutines in an object. Although there are many ways to derive OO interface from procedual one, it's difficult to choose one of them :(


Comment on Re^2: Module provides both of functional interface and object-oriented one
Re^3: Module provides both of functional interface and object-oriented one
by Anonymous Monk on Feb 17, 2012 at 08:03 UTC

    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.

      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.
Re^3: Module provides both of functional interface and object-oriented one
by Anonymous Monk on Feb 17, 2012 at 08:16 UTC

    On the other hand, there's nothing that forbids you from creating wrappers which you can export. Adding to my previous code:

    @EXPORT_OK = qw/get_bar/; sub get_bar { my $var = shift; # your $blosxom::header hashref bar($var, @_); }
      If a module looks as follows:
      package Foo; @EXPORT_OK = qw(get_foo); sub new { # constructer } sub get { # for OO interface } sub get_foo { # for procedural interface } 1;
      users may write as follows:
      $o = Foo->new(); $o->get($key); # of cource, $value $o->get_foo($key); # what's this?
      If users choose OO interface, they shouldn't be able to call 'get_foo' method. How can I solve this problem?

        If users choose OO interface, they shouldn't be able to call 'get_foo' method. How can I solve this problem?

        I'm not very well versed in Perl's OO, so someone please correct me if I'm wrong, but I don't think you can forbid users from calling it. The only thing you can do is throw an error on unexpected arguments.

        (There is a convention that a class's private methods' names begin with the underscore character, though.)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://954409]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (13)
As of 2014-07-22 15:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (117 votes), past polls