>>>>> "MF" == Matt Fowles <[EMAIL PROTECTED]> writes:
MF> Currying obviates the need for everything but a sub callback. If you MF> want a callback to a method, curry the object. If you want private MF> data, curry the data. After you are done currying you will have a MF> simple sub to pass in as the callback, the peasants rejoice, and MF> libraries will have a simpler interface. >> >> i like the concept but how would that work without actually creating >> closures? to convert a sub call to a method on an object is code, not >> just presetting args (which is what i gather currying is). now just >> using a closure would work but i am not in favor of allocating them just >> for this when other optional args can do the job. even with the full >> interface as i want it, you can use closures as your callbacks and keep >> it shorter. i just don't see the win of more code vs more args. MF> Curried functions are most likely implemented as closures internally. MF> But perl6 has C< .assuming > which does most of the ugly syntactic MF> work of creating the closure for us. As for the cost of allocating MF> the closure, I tend not to worry about that till I know it is a MF> problem. Most callbacks are created once and called many times, so MF> the allocation costs are not a great concern. i was more curious about the syntax of a sub that curries a method call on an object. it seems to me that you need actual code to call the method. the currying only presets args (or clear me up on that). there is no way for the args to magically assemble themselves into a method call on that object without some perl code. that makes it a real closure and not something as simple as currying. MF> On the other hand, I view a simpler interface to a library as a big MF> win. Yes, optional arguments could be added which allow for such MF> things, but then the library has to document and manage all of these MF> arguments, and the library user has to learn them all. documenting the ways to create needed closures seems to me to be more complex than just documenting more arguments. there is no new concept to teach (few even understand or use closures in p5) nor new syntax to describe. even if you reduce the main callback to a single arg, it needs a name as it is optional and you save only one named arg (either the object or method). what about the optional timeout callback? in most cases (at least how i do it) that callback wants to use the same object as the main callback. so this would mean two closure args. in the common case of fully named args, you could have the method/sub names defaulted (say to socket_connected and connection_timed_out) and then all you need is the single object argument. so that is fewer args to pass and to know for the common case. and this gets you a nice way to differentiate between sync and async open_socket calls. if it has an object arg (could be a class name too), then it does callbacks to that object which makes it async. it could handle a string as a sub name (symrefs lurk here) or a CODE ref. the internals can figure that out easily now. <ODD ASYNC RANT> a particular odd variation is to let real sync calls act like async calls. this is so you can write a module with socket calls and i/o and have it run sync in some cases (e.g. single scripts) or async in others (long lived demons). so the code is the same but with callbacks in all socket calls. some other vaguely global option will enable all those calls to be async in reality if desired. since the callbacks control the behavior, this means the same module can be used in both ways. this is how i wish many of cpan's socket modules were written. if they completely isolated requesting i/o from handling the results, then it would be easy to use them in sync or async style. </ODD ASYNC RANT> anyhow, we can't keep arguing about arguments. tomato/tomahto and all that. and there will always be modules to change the api to your own favorite api style. my main point was that socket calls do have many more args than plain open and having them in a large slurpy list is bad. they need to be properly named (but optional and with some useful defaults). exactly how they are named and organized is less important to me than having all the needed options (like callbacks) in there. and this brings me back to another point about how async stuff will behave in a normal op loop (and not an event loop). i have yet to see a solution to this (nor barely seen it discussed). e.g. an async (non-blocking) socket connect is made. a callback maybe done later. what is the code doing now? how will the mainline code know when the callback is done? it can poll some data (or a semaphore or whatever) that the callback sets but that is wasteful. the other classic solution is to provide a wait call (waiting on again some data or semaphore or what) that internally does a blocking call to select/poll/whatever. this can also have a timeout which can be used too. i think a 'wait' func should be in the language as well as a basic event loop type of thing. they should be standard (at worst core modules) so we don't get different incompatible event loops and related stuff. 'nuff for now. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
