On Thursday, August 23, 2001, at 12:02 , Ohad Rodeh wrote:
>
> A few comments about the new socket interface:
>
> [...]
> 4. Why not use a simple sum type for socket options. Here's what we do
> in
> Ensemble:
>
> (* Options passed to setsockopt.
> *)
> type socket_option =
> | Nonblock of bool
> | Reuse
> | Join of inet
> | Leave of inet
> | Ttl of int
> | Loopback of bool
> | Sendbuf of int
> | Recvbuf of int
> | Bsdcompat of bool
>
> (* Set one of the above options on a socket.
> *)
> val setsockopt : socket -> socket_option -> unit
I thought of this. It makes getsockopt a pain to use.
Sure, you *could* use a pair of similar variant types, e.g.--
type getsockopt_t = [ `Reuse | `Join | `Leave (* | ... *) ]
type setsockopt_t = [ `Reuse | `Join of inet | `Leave of
inet (* | ... *) ]
val getsockopt: socket -> getsockopt_t -> setsockopt_t
val setsockopt: socket -> setsockopt_t -> unit
...but then you have to do a pattern match on the result of getsockopt
and that seems overly messy to me. And, if you're like me and you want
to communicate with weird Darwin NKE's, it's difficult to add new socket
options.
With my proposal, you get to write code that looks like this:
let acceptconn = Unix.SO_ACCEPTCONN.get socket in f acceptconn
As opposed to:
match Unix.getsockopt socket `Unix.SO_ACCEPTCONN with
| `Unix.SO_ACCEPTCONN yes -> f yes
| _ -> assert false
Adding a new socket option is a simple thing. Define a new module with
the type of the option, and the values of the level and the name. Then
use the functorial. (Though, the more I think about it, I suspect the
'external' interface semantics are going to make it easier if the the
input signature contains the external functions for the specified type.
This is an extra complication, but not one that can't be managed, I
think.)
> Anyway, have fun with caml.
Loving it. I never want to go back to C++ or Perl again.
--
j h woodyatt <jhw@wetware.com>
"You're standing on sacred ground. Many strange and wonderful
things have transpired right where you're standing."
--unattributable
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr