Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^9: IO::Lambda: call for participation

by xdg (Monsignor)
on Jan 06, 2009 at 13:55 UTC ( #734435=note: print w/ replies, xml ) Need Help??


in reply to Re^8: IO::Lambda: call for participation
in thread IO::Lambda: call for participation

How about "conditions" instead of "predicates"? Also, at the expense of changing your API, it might be clearer if the functions names themselves were less like perl functions and more intuitively descriptive.

  • read -> readable
  • write -> writeable
  • sleep -> timeout
  • etc

My thought is that since these aren't actually executed immediately, it would be better to have names that describe the activating condition rather than names that sound like an imperative.

For documentation, I'd strongly suggest separating the perl signature from the context arguments. E.g.

read($callback) -- context stack: $filehandle, $deadline = undef

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.


Comment on Re^9: IO::Lambda: call for participation
Download Code
Re^10: IO::Lambda: call for participation
by ww (Bishop) on Jan 06, 2009 at 14:18 UTC
    Aaargh!

    FumbleFingers managed to select the wrong radio button resulting in an unintended (and thoroughly wrong) downvote on a node which actually deserves ++ for two wise recommendations. Apologies to xdg and all other Monks.

      No worries. :-)

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re^10: IO::Lambda: call for participation
by dk (Chaplain) on Jan 06, 2009 at 18:37 UTC
    Hmm.. Indeed, read() and write(), being the first predicates implemented, stemmed from classic on_read and on_write, and by doing that I deliberately walked away from the on_xxx semantics. I agree that besides being an established API, there are not many arguments against switching from read to on_read or readable. However, do you think that the other conditions should be renamed too? How about names in the neighbor modules, such as connect(), dbi_select(), dns(), etc so many? Or, let me rephrase, how important is presence of on_ in on_read? Even though I'm more inclined in converting "read" into "readable", I doubt that this can be done unambiguously for all cases, like it is with the "on_" prefix. Possibly that decision sacrificed clarity for the sake of brevity. But possibly not, I don't know really.

    As for the second advice, I agree. If the absence of perl signature causes confusion, the signature shall be added.

    On the side note, I'm thinking about all the advices given, and I see that deciphering the information compacted into the current manual could result in a fairly large article. I'm thinking to write it using a wiki or something, I don't know, I never done anything like that, so that the documentation and the module itself will be subject of discussion while being written, not postfactum. As soon as I write a first draft, I'll post it here for review.

    Again, thank you for not giving up and digging further!

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (19)
As of 2014-07-31 14:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (249 votes), past polls