Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!steinmetz!sunlight!guilford From: guilford@sunlight.steinmetz (jim guilford) Newsgroups: comp.sys.amiga.tech Subject: Re: Resources, sets, and abstract datatypes Summary: Why wouldn't libraries do the job Message-ID: <10881@steinmetz.ge.com> Date: 18 May 88 11:07:13 GMT References: <5920@well.UUCP> <957@sandino.quintus.UUCP> <5483@utah-cs.UUCP> Sender: news@steinmetz.ge.com Reply-To: guilford@turing.cs.rpi.edu (Jim Guilford) Organization: RPI Computer Science Department Lines: 107 In article <5483@utah-cs.UUCP> thomson@cs.utah.edu.UUCP (Richard A Thomson) writes: >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". >> >> 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. > > >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? > > >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. > >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. > > -- 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. It seems to me that libraries can very easily provide many of the features of ADTs. It would be nice to take an editor, and add a graphic object to it. The editor would not have to know anything about the object, except that it had a minimum set of commands that it understood. Then in order to add a new object all one would need to do to add a new object is to write an appropriate library and tell the editor where it is. Instantly, your drawing probram now understands pie charts (e.g.). I would have problems with making a huge list of 'reguired' commands to be added to the library vectors. The sort of commands one would need are so diverse, that the list would be huge. I would suggest the following: you add one reguired function to the library vector. This would be a name mapper. When one first loaded the library (ADT), one would pass the mapper a string for each command you expected it to have. The mapper (who knows what is actually in the library) would pass back the address of the function which implements it (or NULL if it is not implemented). Thereafter (since the library can not move within memory), the user program would just call the pointer to the function. There would have to be some degree of standardization for the names used for functions (e.g. 'create' 'new' 'make'?) so that different programs can use the same ADTs, but that is another issue. In this way, one would not have to create stubs for many unsupported functions and worry about conflicting with others when you need to add new functions. Given a sufficiently verbose string, the chance of collisions would be small. The program would not need to know anything of the structure of the library (besides where the mapper lived), although the library would need to know the names of the functions needed. Additionally, one could build an ADT on top of another. This would be nothing more than having one library call another. It could intercept certain calls, possibly pass them through, or possibly ignore them. If it chose to ignore a function, its mapper would call the mapper of the function it was based on, and return that value. Then any calls to that function would go directly to whoever handles it. The main implementational problem is getting a nice way to make libraries out of code (and possibly a way to automagically generate the mapper code). The main functional problem I see with this approach, is that the user has to know what type an object is in order to call the proper routine. I can not write a handler to deal with a generic object. This could be handled in the following way. When each ADT is loaded, an initialization function is called with a pointer to a global data structure. This contains (among other things) a counter, so that each ADT is given a unique small integer id. Then when the mapper is called, it returns instead of a pointer, a unique small integer value. The global data structure has an array of descriptors for each ADT each containing an array of pointers to functions. Each instance of an ADT has at the beginning of it the small integer id value for that ADT. Then when anyone wants to perform a function on an ADT (send it a message?), one calls a router routine with the object, the id of the operation, and the parameters needed. The router looks the ADT-id and operation-id up in its tables and branches to the appropriate routine. The reason I want to map strings into small integers is to avoid having to do a string based table search on each function call, and at the same time keep long descriptive names (sharing numbers between many applications just doesn't work). It seems to me that this would provide all of the useful features of dynamically loadable ADTs. What do people think? Could this work? Are there problems with it or changes that would need to be made? Would this be a useful system or would it just sit on the side and gather dust? --JimG guilford@turning.cs.rpi.edu guilford@csv.rpi.edu ....!rutgers!nysernic!rpics!guilford --------