Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: async interface

From: rotenca:telvia:it at: 6-Mar-2004 0:47

Hi Anton,
> The advantage of that over a single function, I suppose, > is so that you can derive from a standard base > object (or choose from several easy-to-use example objects), > with the four functions [connect read write close] inside. > > I would be happy with that, if that was what you were thinking.
Yes. To limit namespace confusion, they could be called: resolve* (?) connect* write* read* peer-close*
> Also, I see that the user code would be simpler, since > you wouldn't need to nest your user code in a switch, > and actually, the error handling when error? :state could > become a function too.
Another solution could send the read error to the read* function, and so on... This requires an argument for functions: read*: func [port value][] value could be an error!, else none (or something else - for furture expansions) But handling errors makes code more complex for every function, perhaps is better your proposal.
> Any other benefits to this approach ?
A default object, perhaps. User can change only what it needs. One problem is where to store the object and how to permit the user to set it. A fast example with the error* and with one argument: ;global word async-feel: make object! [ error*: func [port err [error!][err] resolve*: func [port value][false] connect*: func [port value [false] write*: func [port value][false] read*: func [port value][false] peer-close*: func [port value][close port true] ] p: make port! [ scheme: 'atcp ;must be used an existing field, like user-data user-data: make async-feel [ read*: func [port value][ print copy port false] ] ] and/or p: open/custom async://abc:3838 [ ;open must do make async-feel this-block async-feel [ read*: func [port value][ print copy port false] ] ] --- Ciao Romano