Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!uwvax!oddjob!ncar!ames!lll-tis!oodis01!uplherc!utah-gr!utah-cs!thomson
From: thomson@utah-cs.UUCP (Richard A Thomson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Resources, sets, and abstract datatypes
Summary: R, S, & ADT = OOL?  (Object Oriented .libraries)
Message-ID: <5483@utah-cs.UUCP>
Date: 11 May 88 05:16:34 GMT
References: <5920@well.UUCP> <957@sandino.quintus.UUCP>
Reply-To: thomson@cs.utah.edu.UUCP (Richard A Thomson)
Organization: University of Utah CS Dept
Lines: 75

In article <957@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>In article <5920@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) posts
>  	for David Joiner (talin @ BIX) regarding Amiga "resources".
>[ lots of stuff left out]
>> future intuitions will have the ability to have customized 'handlers' for
>> windows/menus/gadgets, which  should be SHARABLE between applications.
>
> Also, programmers should be able to write 'handlers' for their own types
> of datastructures.  ... one of the biggest flaws of IFF [is that] any
> application that wants the data has to have my code linked in.

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.

> ... easy
> integration of programs is the ability to define abstract datatypes [that]
> are loaded and unloaded as needed, and can be shared between applications.

BUT, this kind of facility for sharing "data structures + algorithms" already
exists on the Amiga.  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?

I always thought the run-time library support of the Amiga was one of the
things that made it unique in its respect because of this.  Perhaps I should
just shut up about it and write my HyperAtlas that works this way.

> In addition, it is important that programs have some easy way to create
> instances of these datatypes, read and write them from/to files, display
> them on screen or printer (where this is appropriate).
	    [ gives examples of why this is a big win ]

Well, what I think you're getting into here is this idea of the "standard"
things that a library should do.  Remember in the library data structure there
are a certain, small number of things for which any standard library must
provide a routine.  The one that comes to mind is Initialize() which sets
up the local, hidden data structures needed by the operation of the library
routines.

>Sorry if I'm being verbose, and/or stating what everyone else is
>already thinking.  Matt and David, is this where you're heading?  Is
>there anything about what I'm suggesting that is more difficult than
>what you had in mind?  Any gaping flaws?

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.

If the function vectors are all the same (i.e. a longer list of 'required'
functions in the library) for all these object libraries, then no programs
will break on attempting to access another library with the same call.

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?

>I hope someone who has BIX access will pass this on to David Joiner
>(Leo?).  Thanks.

I double this sentiment.

					-- Rich
-- 
USnail: Richard Thomson, Design Engineer, Oasis Technologies, 3190 MEB,
        University of Utah, Salt Lake City, Utah  84112
ARPA: thomson@cs.utah.edu	FONE: (801) 584-4555:      Talk to a machine;
UUCP: {bellcore, ihnp4, ut-sally}!utah-cs!redpine!thomson     they're lonely.