Embedding "database" features into other modules.

First-class modules are allowing me to neatly unpack table implementations into

other modules, using local types.

This is really quite basic, but I wonder if I could have done this before

first-class modules, and without leveraging the object system? I also don't

recall seeing first-class modules used for something like this.

So, is there another way to do this, aside from the object system? It's very

much like creating a basic object.

This is an extracted and simplified example...

--------------------

module Db = struct

  (* Signature for a single 'table' in the database, elements of type t. *)

  module type S = sig

    (* Full implementation relies on a Key module for different key types than 'int' *)

    type t

    val get : int -> t

    val set : int -> t -> unit

    val del : int -> unit

    val iter : (int -> t -> unit) -> unit

    val fold : (int -> t -> 'a -> 'a) -> 'a -> 'a

  end

  (* Instantiates storage for a table, and returns FC module to interact with the store. *)

  let create_with_default (type s) ?(size=19) default =

    (* Full implementation is parameterized by Key and Table modules *)

    let h = Hashtbl.create size in

    let module H = struct

      type t = s

      let get (id:int) = 

        try Hashtbl.find h id

        with Not_found -> default

      let set id (v:t) = Hashtbl.replace h id v

      let del id = Hashtbl.remove h id

      let iter f = Hashtbl.iter f h

      let fold f init = Hashtbl.fold f h init

    end in

    (module H : S with type t = s)

end

(* An example table... *)

module Location = struct

  let unknown = "Unknown"

  include (val (Db.create_with_default unknown) : S with type t = string)

  (* Location might have a bunch of other functionality as well... *)

end

(* and basic usage... *)

# Location.get 1;;

- : Location.t = "Unknown"

# Location.set 1 "Mars";;

- : unit = ()

# Location.get 1;;

- : Location.t = "Mars"

--------------------

Some background on what this is for: (skip unless you're interested!)

I use a "component architecture" with most games -- basically a database of

properties keyed off "game object IDs". I thought this was a very powerful

feature in old MUDs/MUSHs. It's one of the first things I tried making when I

started in OCaml, but I had some difficulties and ended up explicity

instantiating hashtables or maps in the global context of various modules.

Sloppy, but workable. (The reason I had difficulty is because I was trying to

create a database of tables which were created at runtime -- not statically

known.)

Recently I decided to fix this mess. I had many modules, each which tended to

have a corresponding "table". Eg. Characteristics, Size, Wounds, Faction,

Inventory, etc. So ideally I wanted a convenient way to embed "database"

functions into such modules while declaring the implementation of the

underlying datastore (hashtable, map, whatever).

This might seem a bit ugly from a functional-programming perspective, but I've

found components to be quite powerful, and overall helps to constrain where

and how mutation happens. "Game state" is generally in flux -- well, it is

everything variable, and can be compared closely with save-game state. Most code

which doesn't update game state can be functional. Actually, it feels creepy to

have a variable assignment in the code, since mutation is generally to game-state

and that's handled through a database. So the resulting style is

functional+database.

 -Tony