<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE message PUBLIC
  "-//MLarc//DTD MLarc output files//EN"
  "../../mlarc.dtd"[
  <!ATTLIST message
    listname CDATA #REQUIRED
    title CDATA #REQUIRED
  >
]>

  <?xml-stylesheet href="../../mlarc.xsl" type="text/xsl"?>


<message 
  url="2002/07/2ed44fafb26311014d214ea830da4a23"
  from="Dave Mason &lt;dmason@s...&gt;"
  author="Dave Mason"
  date="2002-07-28T21:45:03"
  subject="[Caml-list] on the design of Dynlink"
  prev="2002/07/0b573ce0f42e95b4d4fbedbd027299d1"
  next="2002/07/9922f6f9613f2b6e0ba1c17ad7d199fd"
  prev-thread="2002/07/8a7dbe7dbec9b94ee39deb2127c733b0"
  next-thread="2002/07/39e30771ef4adfd2f12faaf023bfdac5"
  root="../../"
  period="month"
  listname="caml-list"
  title="Archives of the Caml mailing list">

<thread subject="[Caml-list] on the design of Dynlink">
<msg 
  url="2002/07/2ed44fafb26311014d214ea830da4a23"
  from="Dave Mason &lt;dmason@s...&gt;"
  author="Dave Mason"
  date="2002-07-28T21:45:03"
  subject="[Caml-list] on the design of Dynlink">
</msg>
</thread>

<contents>
I am curious about a design feature of Dynlink.

Assume module C uses module B and module B uses module A.

If A loads B and C, then it seems that C can see all of A and
everything it depends on.  This seems like a very unfortunate outcome,
because it means (for example) that C can now use Dynlink itself to
load things, and there is no way for A or B to provide an interface to
hide things from the modules that (transitively) use them.

Now, I understand how to work around this (provide a Registry module
that A calls to register the functions that it wants to provide to B
and C and then they call the Registry to get those values).  But that
is not a very intuitive style, and can make it difficult to extend B
in a completely general way unless, for each module B, I provide a
B'Registry and always load the pair.

Have I misunderstood something, or if I have it right, is there any
hope for this to work differently in future?

Thanks  ../Dave
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

</contents>

</message>

