All~ On 5/3/05, Uri Guttman <[EMAIL PROTECTED]> wrote: > >>>>> "MF" == Matt Fowles <[EMAIL PROTECTED]> writes: > > MF> All~ > MF> On 5/2/05, Uri Guttman <[EMAIL PROTECTED]> wrote: > >> >>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: > >> > LW> multi sub opensocket ( > LW> Str +$mode = 'rw', > LW> Str +$encoding = 'auto', > LW> Str [EMAIL PROTECTED]) returns IO; > >> > >> and how will that support async (non-blocking) connects? or listen > >> sockets? i assume this is sorta the replacement for IO::Socket which is > >> a pure key/value api (except for the shortcut single arg host:port > >> which is nice to also support). for async you need to provide a callback > >> in the signature (beyond all the other socket args), an optional timeout > >> (with its own callback). the callbacks could be defaulted to subs in the > >> current module/namespace but the coder may also want an OO callback > >> which needs an object and method. another little optional argument is a > >> private data field. sure an object callback could handle on a per object > >> basis. but what if one object wanted to manage multiple async socket > >> connections? each one needs to be identified in the callbacks which is > >> what the private data is for. it is passed as an arg to the callback > >> sub/method. > > 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.
Curried functions are most likely implemented as closures internally. But perl6 has C< .assuming > which does most of the ugly syntactic work of creating the closure for us. As for the cost of allocating the closure, I tend not to worry about that till I know it is a problem. Most callbacks are created once and called many times, so the allocation costs are not a great concern. On the other hand, I view a simpler interface to a library as a big win. Yes, optional arguments could be added which allow for such things, but then the library has to document and manage all of these arguments, and the library user has to learn them all. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
