"ocaml_beginners"::[] Re: module rec

Hi,

dmitry grebeniuk < gds-mlsts%40moldavcable.com">gds-mlstsmoldavcable.com> writes:
> Can you describe your situation, where recursive modules was
> heavy-weight for you?
Maybe my words is a bit misleading. What I mean "heavy-weight&quot; is not about
efficiency, just some awkward restriction of recursive module, e.g. all of
them have to be sub modules in a big module and can't be split into small
files.

&gt; I have a more complex structure, so I can't declare type my_struct
> inside module State (which should be the only module that able to
> create/modify state_t). Something like this:
&gt;
> type my_struct = ...;
>; module SomeBigModule1 = ... it uses my_struct ...;
>; module SomeBigModule2 = ... it uses my_struct and SomeBigModule1;
>; module State = ... here I want to declare private type state_t.
> ... this module uses my_struct, SomeBigModule1
> ... and SomeBigModule2;
>; module SomeBigModule3 = ... uses my_struct, SomeBigModule1,
>; ... SomeBigModule2 and module State;
&gt;
> If I declare private type state_t together with type my_struct,
> I won't be able to create/modify values of this type inside
&gt; module State. And I can't move module State before BigModules1
> and 2 because module State uses them.

I roughly understand your situation, but I don't understand the design,
especially the reason why you want the state_t type private (or opaque) to
all other inside modules. If all these modules are programmed by you, why
do you care whether they can operate over state_t type directly?

Messages in this topic (4) Reply (via web post) | Start a new topic

.