Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!stanford.edu!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga.programmer Subject: Re: HYPER FUNCTIONALITY Message-ID: <1991Apr25.073105.23324@agate.berkeley.edu> Date: 25 Apr 91 07:31:05 GMT References: <2407@swrinde.nde.swri.edu> Sender: root@agate.berkeley.edu (Charlie Root) Organization: University of California, Berkeley Lines: 68 In (24 Apr), Matthew Dillon (dillon@overload.Berkeley.CA.US) writes: > > My thoughts were that hyperfunctionality could be obtained through > dynamically linked object modules. You would basically have a > shared library that has the following calls: > > func = GetHyperFunc("display_bitmap") > > ... use function ... > > RelsHyperFunc(func) > Hmm. Yes. I like it. [Not that I think it replaces or supersedes ppIPC, you understand... (:-)) All these various approaches have rather different areas of applicability, and independent, multitasked, processes will often be a better solution. I don't see Kent's system, or a MIDI net, say, being done with dynamic linking.] Some comments on its present stage, however: > (3) The shared library searches for and finds the appropriate > third party module containing the function and dynamically > links it to the parent. This would probably have to be something more elaborate than a "search path", so that the user could specify for a given parent module which version (there might be several on file) of a function was required. > (5) STANDARD FUNCTIONS > > Third parties, the net, whoever, can define defacto standard > functions such as 'IffToBitmap' with standardized arguments > and standard return values, then others can improve on the > initial offering by producing compatible modules that use > the same call/return interface. > I think you would need some way for the caller to specify the argument structure of a function as well, at the HyperFunc(..) point, to ensure that things matched properly. Someone is bound to want to change a function's spec at some point, and this is a sure path to calamity unless there is a check. The lib_fd entry already provides the template at the other end (or a lot of it anyhow). You might even want to extend this to some form of "Polymorphism" (a la Object Oriented Programming). The caller's declaration of the type of data that was to be passed would then be taken into account in selecting the appropriate matching function. This could help reduce an otherwise large namespace. > > The first key to all of this is 'THIRD PARTY' ... 'MIX AND MATCH' ... Ahh yes -- the magic keywords.(:-)) I've been using the same ones in my advocacy of ppIPC for quite a while... > > The third key is in the dynamic linking capability. Note, I have written > a shared library that does dynamic linking into a running program by > searching for it's executable and symbol table, but in my opinion > this particular capability -- linking to the calling process's symbols, > is a BAD thing. Agreed -- I didn't like THAT scheme much at all...(:-)) This one is a lot more promising. -- Pete --