in reply to coding a subroutine as both method and regular function

Perhaps the reason you came up empty looking for people doing this is because they don't since it's not that great of an idea . . .

Update: Rather than making this tree deeper than it already is I'll elaborate here.

As is pointed out below, the suggestion is for the developer to choose between OOP and a procedural interface when designing the API. It's not an exhortation to provide $your->cake() and eat( $it => 'too' ), rather to look at the problem at hand and decide (using the criterion outlined in the following section of that chapter) if OOP fits better or if procedures fit better.

I've been trying to think of any "big" module which provides both ways simultaneously, and other than CGI I can't. And as has been commented below it's not a pretty picture how it allows this.

If you want an example of how I'd provide both interfaces (were I made to :) then consider LWP::UserAgent and LWP::Simple. The later provides a procedural interface, while the underlying module is still accessible for those needing more controll.

Replies are listed 'Best First'.
Re^2: coding a subroutine as both method and regular function
by leocharre (Priest) on Mar 22, 2007 at 16:02 UTC

    I have no doubts at all that you know what you're talking about- That said, could you please give some hints ideas suggestions as to why this is a bad a idea? Really, I just don't want to write bad code.

    And, when Damian Conway (Perl Best Practices) suggests offer oo as 'option' not a default.. this is not what he's talking about?

    So instead, in this example.. I should make a set_meta() and a _set_meta() ? That is, to satisfy that a package offer both procedural and oo api.

[reply]
      And, when Damian Conway (Perl Best Practices) suggests offer oo as 'option' not a default.. this is not what he's talking about?

      Actually Damian says 'make it a choice, not a default'. I don't think he's referring to the user of the module/class, but the developer of it. So he's suggesting that you don't assume that every module you implement should inherently be a class, but that a non-OO implementation may just as good or a better choice in a given scenario. 

      perl -e 'split//,q{john hurl, pest caretaker}and(map{print @_[$_]}(joi
+n(q{},map{sprintf(qq{%010u},$_)}(2**2*307*4993,5*101*641*5261,7*59*79
+*36997,13*17*71*45131,3**2*67*89*167*181))=~/\d{2}/g));'

      [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom