<hcarty>
joelr: If you want to use functors, the classes would have to be wrapped in modules (and their names would have to start with lower case letters)
<joelr>
oh...
<joelr>
i thought i could just pass random types in
<hcarty>
In that case you probably want to use functions and/or some OO pieces
<joelr>
it seems silly to wrap classes in modules
<joelr>
hcarty: i'm stuck with classes as these are generated from thrift-ocaml
<hcarty>
I think Jason Hickey's book has a decent chapter on OO vs modules
<joelr>
so, why is it that i can do 'class t (i,o) ='
<joelr>
but cannot do 'module type X(i, o) = '
<hcarty>
Functors are parameterized over modules
<rproust>
you can do module X (Y:sig val i: int val o: unit end) = struct ... end
<hcarty>
Classes are parameterized over values (and maybe classes?)
<hcarty>
Functions are parameterized over all of these, as of 3.12.0
<joelr>
rproust: can i do this with module type?
<gildor>
joelr: just read what you said before, about oasis
<joelr>
gildor: yes?
<gildor>
joelr: I think you want something like oasis-db "install" subsystem
<joelr>
gildor: would this be local to the project? because i can already install into /usr/local/... with findlib and oasis
<gildor>
joelr: i.e. something to manage a set of oasis package, including some for which you are upstream
<joelr>
rproust: i need module type X(i,o)
<joelr>
basically, parameterize over two types
<gildor>
joelr: when you are upstream you can register the directory of the project
<joelr>
gildor: i need this for an internal project, private to the client. i reckon oasis-db is something more global, though
<gildor>
joelr: and have it rebuild using "oasis update" which will also includes rebuilding project that depends on it
hto has quit [Quit: Lost terminal]
<gildor>
joelr: the "install" subsystem is remote for package where you are not upstream and local for your package
<joelr>
rproust: docs show examples with 1 type that's a module, though. do i (as hcarty said) need to wrap classes in modules then?
<joelr>
gildor: what is being upstream?
<gildor>
joelr: e.g. you depend on "extunix", "sqlexpr" and "mylocal1" in project "mylocal2"
ymasory_ has joined #ocaml
<gildor>
upstream = you are the author of the project
<gildor>
joelr: ^^^
<joelr>
ok
<rproust>
joelr: module type F = functor (M1 : M) -> N
<joelr>
rproust: thanks
<joelr>
trying
<gildor>
joelr: extunix and sqlexpr will be downloaded from oasis-db whereas mylocal1 will be local
<rproust>
joelr: with M a module type containing the specs of your two classes
<gildor>
joelr: but this is only a project for now
<gildor>
joelr: I am working on it and hopefully, in one month it will be released
<joelr>
rproust: does that imply that M needs to be fixed in the signature of the functor or that I can pass that in at runtime? because i'm trying to parameterize over M
<joelr>
what i'm trying to do is create a module that can use the request and response classes from any given modules, as well as the read_response and read_request functions
<joelr>
rproust: problem is that the latter functions always have the same signature while the classes request and response always have a different set of methods
<rproust>
module type INTERFACE = sig class toto : object method foo: unit end end
<rproust>
module type FUNCTOR = functor (M1:M) -> sig val read_toto: M1.toto end
<joelr>
rproust: i cannot fix M at compile time
<joelr>
rproust: see gist above
<joelr>
M is known at instantiation time but not in the type signature of the functor
<rproust>
it doesn't have to
<joelr>
rproust: so i can literally say (M1:M)?
<rproust>
M can be dynamuic, but M1 is fixed at compile time
<joelr>
i see...
<rproust>
mo
<rproust>
the other way around
<thelema>
joelr: module type Reader = sig type req type resp val read_request: Protocol.t -> req val read_response: Protocol.t -> resp end
<rproust>
M is the interface that needs to be known at compile time
<joelr>
rproust: what thelema said :) i just hit on it the very same moment
<joelr>
:D
<joelr>
is there a way to specify a class type that has at least a write method of a given signature, e.g. to avoid this error
<joelr>
Error: This expression has type E.response but an expression was expected of type < write : TBinaryProtocol.t -> 'a; .. >
<thelema>
what happens if you remove the TBinary part of 'a writable?
<joelr>
checking
ulfdoz has quit [Read error: Operation timed out]
<joelr>
doesn't work. Values do not match: val request : unit -> T.request is not included in val request : unit -> < write : Thrift.Protocol.t -> unit; .. > U.writable
<thelema>
ok, try a cast: let request () = (new T.request :> 'a U.writable)