From: j h woodyatt <jhwoodyatt@mac.com>
To: "Ohad Rodeh" <ORODEH@il.ibm.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Unix.socket_option in ocaml-3.0.2
Date: Thu, 23 Aug 2001 10:19:51 -0700 [thread overview]
Message-ID: <200108231719.KAA15162@smtpout.mac.com> (raw)
In-Reply-To: <OF40593E9A.699E9546-ONC2256AB1.0025CB91@telaviv.ibm.com>
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
next prev parent reply other threads:[~2001-08-23 17:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-23 7:02 Ohad Rodeh
2001-08-23 17:19 ` j h woodyatt [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-08-22 22:45 j h woodyatt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200108231719.KAA15162@smtpout.mac.com \
--to=jhwoodyatt@mac.com \
--cc=ORODEH@il.ibm.com \
--cc=caml-list@inria.fr \
--cc=jhw@wetware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox