http://www.perlmonks.org?node_id=339053


in reply to Re: Re: Ingy's "Swiss Army Light Sabre" - or, "how do you design your APIs?"
in thread Ingy's "Swiss Army Light Sabre" - or, "how do you design your APIs?"

FYI -- my comments about 'theory of operations' and the need to have a heavy and strict order of method calls (see PAM code in C, the Windows API, Java socket API's, whatever) is annoying and could be cleaned up -- but that's not a comment about IO::All, but rather API design in general.

You lost me when you speak of 'an orthogonality argument', what are you proposing should be othogonal to what? Again, the commentary of IO::All is just interlaced into my post as reference, I think the '>' operators are indeed (1) succinct but are not (2) obvious enough. My biggest issue with API design is that API's are not clean and succint enough, and IO::All does a good job in this case. But it's sketchy when it comes to expected behavior, IMHO -- there are obviously tradeoffs to consider between the two.

  • Comment on Re: Re: Re: Ingy's "Swiss Army Light Sabre" - or, "how do you design your APIs?"

Replies are listed 'Best First'.
Re: Re: Re: Re: Ingy's "Swiss Army Light Sabre" - or, "how do you design your APIs?"
by kal (Hermit) on Mar 23, 2004 at 16:13 UTC

    The "othogonality" I was referring to (I should stop using that word; it's ugly) was about being able to use the overridden operators in all circumstances. You expected something to work, and it didn't, because of the circumstance.

    I have to say, I like both the '>' and '>>' operators - they work just like in the shell, pretty much. '>>' is also a bit C++-ish. But, maybe it's just my brane.

      You expected something to work, and it didn't, because of the circumstance.

      The > operator is kind of difficult since it is really meant to be used in a boolean comparison. Perl will usually issue a warning if it is used in a void context (which makes sense). I had actually implemented both the > & >> operators in a file class I wrote once, and I found myself writing code like this to avoid warnings.

      ($f > "writing this to my file") || die "cannot write to file for some + reason";
      Its a little overkill, but the project requirements actually dictated this level of strictness so it worked out.

      IO::All actually catches the warnings, and dismisses them:

      # line 800 in All.pm if ($_[0] !~ /^Useless use of .+ \(.+\) in void context/) { goto &$old_warn_handler if $old_warn_handler; warn(@_); }
      Which IMHO is kinda dangerous as it hides real warnings too. But hey, TIMTOWTDI i suppose.

      In the end, Perl's overloading is great, but is somewhat limited in the sense that the original "intention" of the operator is somewhat retained. Of course, you could also view this as a good thing, as it prevents people from doing really weird stuff.

      I have to say, I like both the '>' and '>>' operators - they work just like in the shell, pretty much. '>>' is also a bit C++-ish. But, maybe it's just my brane.

      Nah, its what coding in C++ has done to your brain, its not your fault. ;-)

      -stvn