Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!princeton!udel!rochester!cornell!uw-beaver!teknowledge-vaxc!sri-unix!quintus!pds
From: pds@quintus.UUCP
Newsgroups: comp.sys.amiga.tech
Subject: Re: Resources, sets, and abstract datatypes
Message-ID: <960@sandino.quintus.UUCP>
Date: 13 May 88 00:07:25 GMT
References: <5920@well.UUCP> <957@sandino.quintus.UUCP> <5483@utah-cs.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 82
Posted: Thu May 12 20:07:25 1988

In article <5483@utah-cs.UUCP>, thomson@utah-cs.UUCP (Richard A Thomson) writes:
> I agree with you that this modularity is indeed useful and that it is
> realizable with the Amiga system.  I don't understand why you say it is a
> problem with IFF, though.  Sure, IFF is an Interchange File Format, but it
> isn't intended to transport code.  It was designed in a way to give file
> interchange between not only Amiga applications but all kinds of applications
> on many different machines.
...
>  What's wrong with the metaphor of the run-time library
> as an abstract datatype?  For that matter, where's the line between the library
> and an object under object oriented programming?

A library can indeed serve as an implementation of a class (or
datatype).  I believe this would work very well.  But there are a few
things missing.  What's missing is the SYSTEM.  The conventions.  There
needs to be a few routines (probably in a library, to keep them shared)
to do things like create an object and read an object from a file or
buffer.  Operations where you don't have an object to operate on yet.
Also needed is a set of rules about coding this way.  Common operations
should all be at the same offset in the library (if libraries are
indeed used to implement this stuff).  If this thing is to include
inheritance, then a mechanism for implementing it must be coded.  It
may not be a great deal of code, but some is required.  More
importantly, a careful design is needed.

> At the risk of being verbose, I still see a problem with regards to the
> implementation of ADTs as a .libary and sharing them among different programs.
> You'll still have to have some kind of knowledge about the library when
> writing the program since you must call the routines in the library.

That's the role of the system.  One way to do it would be to have each
.library somehow include the list of operations it supports and
the function vector offset for each.  The .library would register this
info with the system (let's call it Abstract Data Type System, or ADTS)
in it's initialization code.  Let's say that the first longword of each
instance (object) in memory would uniquely determine the type (class) of
the instance (a la IFF).  When a message is to be sent to an object, the
message name would be a string, which the ADTS would turn into a library
function vector offset.

If you want inheritance, that's not too hard, either.  When a .library
is registering itself with the ADTS, it would say that it's a subclass
of some other class (whose library would then be loaded).  The ADTS
would then give this .library all the methods of the parent (except
those it defines itself).  Not too hard.  It just requires that the ADTS
record the library base, as well as the offset, for each class/message
name pair.  (Otherwise you could just store the offset for each pair,
and the base once for the datatype.)

There are some other wonderful things this could bring, but I'll discuss
them in another posting.

It would be nice to be able to have a single mapping of method name ->
function vector offset.  I'm afraid, though, that since the offsets are
determined at the time the library is constructed, that will not be
possible.  Anybody have a way around this problem?

> Perhaps the way to do a hyper-card like thing is to have a bunch of these
> object libraries around PLUS an extra library that has all your scripting
> support routines (Arexx?).  Then multiple scripts share the script library,
> so they are small.  Any objects not being used (i.e. the library use count
> is down to zero, but the library is still hanging around in memory) will
> be thrown out by Exec.   Suggestions anyone?

Seems reasonable.  It might be better, though, to define "hypermedia"
as a class, which would (eventually) have lots of subclasses.

I think, as I said earlier, that such a system, if adopted as a standard
and blessed, like IFF, would make the Amiga the best-integrated system
going.  It would capitalize on one of the features of the Amiga that
even Unix systems haven't caught up with yet:  shared libraries.  But in
order for this to happen, it MUST be blessed.  So I hope people that are
interested in this sort of thing (Matt?  David?)  can get together and
agree on an approach, and that CA can get involved at some point.

Leo?  You still there?  Could you (or anyone with BIX access) please
pass this on to David Joiner again?  Thanks.  (Why isn't there a BIX
gateway?)
-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds