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.