Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

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

by flyingmoose (Priest)
on Mar 23, 2004 at 15:59 UTC ( #339053=note: print w/ replies, xml ) Need Help??


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?"
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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (9)
As of 2014-07-25 02:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (167 votes), past polls