Re: Back-end HOWTO

[acken@informatik.uni-kl.de]

>  From: Guy Laden <laden@math.tau.ac.il>
>  Date: Sun, 4 Feb 1996 23:57:35 +0200 (GMT+0200)
>  
>  Michael - if you dont have any objections (and I seem to read
>  between the lines that you dont) I'd like to maintain and extend
>  the HOWTO document. Please Let me know if you'de rather maintain
>  the document yourself. Otherwise, I thought a www page, at
>  least while the document is be updated frequently, would be a better
>  distribution format. Ofcourse periodic posts to the mailing-list can be
>  sent.

I'm more than happy to hand this task over to someone who is more
concerned with back-end issues than I am.  I assume that everyone on
this list has WWW access?

>  I'm assuming you meant suggestions for OOC related projects. Here goes...
>  I'm not sure what scheme is currently used in OOC for doing consistency checks,
>  but I'm guessing its based on a per symbol-file key.
>  Implementing the scheme described in R. Crelier's thesis would
>  greatly increase the granularity of the consistency checks.

The benefits from integrating one of Crelier's symbol file extension
mechanisms are not that great.  They increase the complexity of the
symbol file reading / writing considerably, either by introducing the
need to read the old symbol file (remember, IO is slooow) and to
compare both versions, or to put lots of fingerprints into the file.
Symbol file extension doesn't allow to introduce new fields or
type-bound procs to records without the need of recompiling all
clients.  Since the current implementation will only recompile the
direct clients of a module (unless a changed type is propagated
through another module), and compilation of a module is a matter of
seconds, I don't see a pressing need to extend the symbol file.  If
someone else wants to do this, fine, otherwise I'll put it at the very
end of my list of possible additions.

>  Yet another possibility is a standard Oberon ADT library.

Without a finished spec of a core library this is idle speculation.
Personally I'd like to see a library to handle GUIs.  This lib should
use a common (O2) interface on all platforms, but present to the user
a look-and-feel that is--as far as possible--modeled after the
established `styles' of the target.

-- mva