Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
Well, if indentation makes the learning curve too steep, I have no problems with reformatting code in docs and examples with the standard indentation, but shall explain the benefits of the {{-style. I agree.

About the choice between on_write, writable, and write, it gets not that simple. While I agree that on_write makes a reader instantly recognize that the coderef is an event handler, it's not that obvious with the higher-level conditions. For example, let's take four conditions declared in IO::Lambda::Socket: connect(), accept(), send(), and recv(). One thing is that they clash the with CORE:: names, which I think is good, at least for the three latter names, because either one uses blocking CORE::send, or non-blocking IO::Lambda::Socket::send. Also, connect() is different by semantics from accept(), send(), and recv(): connect() doesn't do anything, it's basically a wrapped writable(), and is the only one that can be renamed to either on_connect() or connected(), without losing its meaning. However, consider send() for example. It waits for a handle to become writable, then sends whatever data provided, and returns the CORE::send() return value.

What I'm getting to, is that the imperative names actually have their niche, they, like in declarative programming, actually order to do something. Now I'm getting into shaky ground, because I don't have that command of the english language that allows me to make statements like the following, but please tell me if there is a sense in that or not. Names like on_write, on_execute, on_ready, they, as I understand, are appropriate when a programmer did some setup and then awaits for an event. This is true for writable and readable, because all the setup is done outside of these conditions. It's not true though for send() and accept(), they themselves do the setup, and it seems to me that there's no place for word other than an imperative to describe their functions.

Let's take for example POE:

POE::Wheel::ListenAccept->new( Handle => $socket, AcceptEvent => ..., )
where AcceptEvent is semantically separated from ListenAccept. In IO::Lambda::Socket::accept, it's not.

So, I was thinking then and also thinking now. on_ and when_ (and for that, Event postfix in POE) have one great property, they unify the event names. Again, my english at best was to counter that with names in imperative modes (is it called modes or moods?), that also are expected to unify conditions. But conditions are not events, while some do look more like events, like writable and readable, the majority of the others do not.

Finally, there are names that I think are very fitting, f.ex. tail and tails. Would that be better to have them changed into on_lambda_done and on_all_lambdas_done? That's too far I think.

I'd like then to ask you, and everyone too, to help me find that grammatical or semantic unifying principle, or at least a division line between imperative and non-imperative conditions, that could be unambiguously declared and easily recognized. These features, I agree with you, are important both for learning and extensibility.

And here's the list of the existing conditions: dns flock process forked http_request message snmpget signal pid spawn connect accept recv send rxw readable writable timeout tail tails tailo any_tail

Out of these signal(), connect(), pid(), rxw(), readable(), writable(), and timeout() are non-imperative.


In reply to Re^2: IO::Lambda: call for participation by dk
in thread IO::Lambda: call for participation by dk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2024-03-29 00:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found