RE: [Caml-list] Module design

[David Allsopp <dra-news@metastack.com>]

Thanks for your reply

pierrchp@free.fr wrote:
> So if I understand you need users to:
>   - be able to customize conenctions ids

Not quite - it's that a given backend may wish to attach additional data to each connection (the processor itself would still use an int to represent the connection). It seems neater to do this in the backend processor (i.e. attach it to the type itself), rather than forcing each backend to maintain a Hashtbl mapping connection IDs to its own data structure.

>   - be able to customize connect or disconnect if they want to
> 
> I think I would keep the idea of having options, and do something like
> this

I guess in simplifying it to create an example, I obscured the fact that there are 13 callbacks and most backends will only override 2-3 of them - which is why I don't like the option approach as much (lots of typing out null stubs). There's also a slight benefit to using "include" with a module filled with defaults - if additional hooks are added, then older backends wouldn't need to be altered (they would simply use the default callbacks).

> type 'a connection =  {connection_id:'a ;
>                       (*some other things that needs to be defined*)
>                        }
>                       (* type of connections *)
> 
> let make_connection connid = {connection_id = connid;
>                             (*some other things that needs to be defined*)
> 			     }
> 
> module type CONN = (* custom connection *)
>   sig
>   val connect: ('a connection -> bool) option
>   val disconnect: ('a connection -> unit) option end

This signature can't work, I think - an actual backend won't be using 'a connection - it will have instantiated a specific one which means that the module won't unify with the signature.

> module type BACKEND = functor (C:CONN) -> sig val connect:'a connection ->
> bool val disconnect:'a connection -> unit end
> 
> 
> module Backend : BACKEND = functor (C:CONN) ->  struct
>    let default_connect c=  (*implement default connect*)
>    let default_disconnect c= (* implement default disconnect *)
> 
>    let connect c = match C.connect with
>          None -> default_connect c
>         |Some f -> f c
> 
>    let disconnect c= match C.disconnect with
>          None -> default_disconnect c
>         |Some f -> f c

This means that the "default" and the actual function are still both included in the final module - I was wondering if there's a way of avoiding that (without using objects) but maybe there just isn't and I shouldn't worry about it! OCaml 3.12 substitution (7.16 in the manual) only allows you to erase types from a module inclusion, not values, sadly.


David


> (* Repeated the pattern matching for more clarity, it can be implemented
> as a function :
>     let analyze default fopt = match fopt with
>          None -> default
>         |Some f -> f
> 
> then you just have to
>  let connect c = (analyze default_connect C.connect) c  let disconnect c =
> (analyze default_disconnect C.disconnect) c
> *)
> 
> end
> 
> 
> -Cheers
> 
> Pierre
> 
> Selon David Allsopp <dra-news@metastack.com>:
> 
> > I'm working on a new version of a framework for a server daemon which
> > can have custom functionality plugged in through different backends.
> > The present version works by passing a record containing lots of
> > options along the lines
> > of:
> >
> > type backend = {b_connect: (connectionID -> bool) option; b_disconnect:
> > (connectionID -> unit) option}
> >
> > which is then passed to a function run which does the actual work,
> > using the callbacks given in the backend record or substituting
> > defaults where None is specified.
> >
> > I'm thinking that a functor would be a much neater way of doing this
> > (and would also allow for passing around more than just a connectionID
> > if
> > required) but wondering what the best way of preserving the ability to
> > have default handlers for functions which a given backend isn't
> interested in.
> >
> > I've not really used the module system beyond trivial functor
> > applications (Set and Map, etc.) but I've come up with the following:
> >
> > (* Framework.ml *)
> >
> > (* Individual connection identifiers *) type connectionID = int
> >
> > (* Wrapper type for custom connections *) module type CONNECTION = sig
> >   type t
> >   val newConnection : connectionID -> t end
> >
> > (* Actual backend type *)
> > module type BACKEND =
> >   sig
> >     include CONNECTION
> >
> >     (* Toy functions, obviously *)
> >     val connect : t -> bool
> >     val disconnect : t -> unit
> >   end
> >
> > (* Default behaviour defined in these two modules *) module Default =
> > struct
> >   (* Default connection information is just the identifier *)
> >   module Connection : CONNECTION = struct
> >     type t = connectionID
> >     let newConnection connectionID = connectionID
> >   end
> >
> >   (* Default functions *)
> >   module Backend (C : CONNECTION) = struct
> >     let connect _ = (* ... *)
> >     let disconnect _ = (* ... *)
> >   end
> > end
> >
> > module Make (Backend : BACKEND) = struct
> >   let run () = (* ... *)
> > end
> >
> > and so an implementation using default connection IDs could be written:
> >
> > module rec MySimpleBackend : Framework.BACKEND = struct
> >   include Framework.Default.Connection
> >
> >   include Framework.Default.Backend(MySimpleBackend)
> >
> >   let connect _ = (* Alternate behaviour *)
> >   (* Default disconnect is fine *)
> > end
> >
> > and one with more complex connectionIDs could be written:
> >
> > module rec MyComplexBackend : Framework.BACKEND = struct
> >   type t = {ci_id : Framework.connectionID; (* ... *) }
> >   let newConnection id = {ci_id = id; (* ... *) }
> >
> >   include Framework.Default.Backend(MyComplexBackend)
> >
> >   let connect {ci_id; (* ... *)} = (* Alternate behaviour *) end
> >
> > This pattern seems to work OK but is there an even neater way I
> > haven't spotted? I'm presuming that in the following:
> >
> > module Foo = struct let x = true let x = false end
> >
> > the compiler doesn't create a module with two fields one of which is
> > inaccessible which would seem to be important (from an aesthetic
> > sense) with having a module of default functions which get "overridden".
> >
> > Any guidance/comment appreciated!
> >
> >
> > David
> >
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa-roc.inria.fr/wws/info/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> >
> >
>