Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] Unix.socket_option in ocaml-3.0.2
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: j h woodyatt <jhwoodyatt@m...>
Subject: Re: [Caml-list] Unix.socket_option in ocaml-3.0.2
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