[Oberon] Oberon for a C++ user.

[Felix Friedrich]

Andreas,

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.

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.

Regards
Felix



> Felix,
>
> 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).
>
>
> 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.
>
>
> 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).
>
>
> But I have refrained from including that in the published version of 
> Experimental Oberon, for several reasons:
>
>
> 1. It makes type tests more expensive
> 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).
> 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.
>
>
> 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.
>
>
> 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.
>
>
> But happy to be proven wrong. With a good use case, I'll publish...
>
>
> Best,
> Andreas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20161121/e68047b4/attachment.html>