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
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
