<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Andreas,<br>
<br>
Understood. Good point that indeed new types in the new module are
in a way uncomparable to the old types of the old module. So, yes,
you are right and the type test should not be changed.<br>
<br>
And also, I agree very much that the (academically interesting)
discussion about the corner cases of module unloading is
additionally merely relevant for the development phase and does
not really apply to production systems.<br>
<br>
Regards<br>
Felix<br>
<br>
<br>
<br>
</div>
<blockquote
cite="mid:A8660808-9C2A-4F4B-94A7-65834F3A75F1@yahoo.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>Felix,</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">Not sure I missed the point. I
believe this *should* be the expected behavior. In my code, the
type test "emitted" by the "new" module are only to be applied
to "new" instances. So for all practical purposes these *are*
different types, yes. And the modules *are* different (except
that they happened to have shared the same name).</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">If it is your intention to make the
type test in the "new" module return also TRUE when applied to
instances created by the "old" module (and vice versa), then
indeed this would require a different implementation. Agree with
that of course.</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">I have actually implemented THAT as
well in a variant of Experimental Oberon. It is not difficult
(the compiler needs to emit different code for type tests - code
that simply runs through all module "versions", old and new, and
then performs the type test which is a simple address
comparison, and it's easy to know from the module list which
modules "belong together" version-wise).</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">But I have refrained from including
that in the published version of Experimental Oberon, for
several reasons:</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">1. It makes type tests more expensive</div>
<div id="AppleMailSignature">2. Keeping "old" and "new" separate
appears to be the cleaner approach. As you said, it's no drama,
really, and programmer can always handle it as well (eg by just
adding another "id" field or something).</div>
<div id="AppleMailSignature">3. It would only be a real solution
if one formally introduces the notion of a "version" of a module
- but that would in turn lead to complex rules on when are two
modules considered to be same, what if I *want* multiple
versions coexisting - and I didn't see the need for that kind of
complexity in the Oberon core - although it's perfectly doable.</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">If you give me a good use case, I may
reconsider and publish a variant of EO that handles multiple
module versions the way you see them.</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">Multiple versions in memory are
mostly occurring during development (so that's not a good use
case), but not in production. The only "good" use case I have
seen so far is on a server environment in a data center where
one might indeed want to have multiple versions of, say, an
Oracle database, hosted on the *same* server. But with the
advent of virtual machines, even that use case has by and large
gone away long time ago.</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">But happy to be proven wrong. With a
good use case, I'll publish... </div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">Best,</div>
<div id="AppleMailSignature">Andreas</div>
</blockquote>
<br>
</body>
</html>