Hi,
On Aug 29, 2008, at 5:28 PM, mark richardson wrote:
[Csv]={Module.link ["x-oz://system/user/Csv.ozf"]}
[QTk]={Module.link ["x-oz://system/wp/QTk.ozf"]}
This code by Mark reminded me of something I wanted to discuss with
you before. Experience (and long debugging sessions!) taught me that
presently one (usually) avoid linking multiple functors with multiple
calls to Module.link. As a general practice, it is wise to have only
a single call to Module.link like
[Csv QTk]={Module.link ["x-oz://system/user/Csv.ozf" "x-oz://system/
wp/QTk.ozf"]}
The problem is that every call to Module.link creates a new module
manager, which can lead to conflicts if functors export stateful
data. It appears that the first module manager is the same as the one
used by functors importing other functors (is there any
documentation on that?), but later created module managers differ.
Now, if any module exports a stateful date structure (e.g., I myself
store user customisation settings in a dictionary), and other modules
or OPI code uses it, then multiple module managers lead to multiple
copies of this stateful data structure. Sometimes, this may be what
you are after. For example, the Application Programming tutorial has
an example which does this in order to create multiple database
instances (see http://www.mozart-oz.org/documentation/apptut/
node4.html).
However, I feel that the standard behaviour of module linking should
be that a stateful data structure is shared, instead of creating
multiple copies of functors and their data. For me, that is the more
strait-forward case than the copying, and as I said the other
behaviour can lead to bugs which are very hard to find. Also, we
already have some programming construct which does create instances
of stateful data structures (namely OOP). I feel that module linking
should be handled differently. At least, I feel both options should
be available: one which always creates a new module manager and one
which does not.
At the end of this mail I post an implementation of ModuleLink and
ModuleApply which always uses the same module manager. I suggest
something like this definition is added to the functor module (mozart/
share/lib/init/ModuleAbstractions.oz). I would even argue that this
implementation should replace the exiting definitions, but at least
we should have these too.
Any comments? Thank you!
Best
Torsten
--
Torsten Anders
Interdisciplinary Centre for Computer Music Research
University of Plymouth
Office: +44-1752-586219
Private: +44-1752-558917
http://strasheela.sourceforge.net
http://www.torsten-anders.de
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
local
ModMan = {New Module.manager init}
in
/** %% ModuleLink is like Module.link except that multiple calls
of ModuleLink share the same module manager (and don't create new
managers as Module.link does). For instance, when ModuleLink links
multiple functors which refer to a stateful datum in some functor,
then all refer to the same datum instance. By constrast, linking with
Module.link results into multiple stateful datum instances.
%% */
fun {ModuleLink UrlVs}
{Map UrlVs fun {$ Url}
{ModMan link(url:Url $)}
end}
end
/** %% ModuleApply is like Moduel.apply expect that it always
uses the same module manager (cf. ModuleLink).
%% */
fun {ModuleApply UFs}
{Map UFs fun {$ UF}
case UF of U#F then
{ModMan apply(url:U F $)}
else
{ModMan apply(UF $)}
end
end}
end
end
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
