Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: HYPER FUNCTIONALITY Message-ID: Date: 25 Apr 91 19:52:38 GMT References: <2407@swrinde.nde.swri.edu> <1991Apr25.073105.23324@agate.berkeley.edu> Organization: Not an Organization Lines: 89 In article <1991Apr25.073105.23324@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: >In (24 Apr), >Matthew Dillon (dillon@overload.Berkeley.CA.US) writes: >> >> My thoughts were that hyperfunctionality could be obtained through >>.. >> (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). Achk! right. I guess it makes sense to use 2.0 style tags, so HyperFunc(...) would be something like: HyperFunc(funcName, ...) And then there would some tags: HT_CCALL, 1, request C calling interface HT_ACALL, 1, request Assembly calling interface HT_CUSTOM, "_fub_", request some other interface Thus allowing for future extensions. >> 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... I think the main problem with all of these things is lack of ease of use (i.e. if the programmer has to do any work at all he winds up not using it). I've been seriously thinking of adding a new keyword to DICE to automate the process, something like: __dynamic void fubar(int, int); main() { ... fubar(1, 2); } Which would completely *HIDE* the HyperFunc() call. Under DICE this is easy, I can have the compiler generate autoinit and autoexit code to set up the appropriate vectors and silently make 'fubar' into a function pointer instead of a function proper. I do the same thing with libraries under DICE now.... you just call OpenWindow() and DICE automatically opens and closes the library for you, make things much easier to deal with and even more portable in the sense that the program source doesn't know it has to open library X to get function Y. I'd like the HyperFunc stuff to work the same way. And, as I mentioned, you can also completely hide cut & paste, your IPC, AREXX, whatever... inside these functions without the program having to do anything to get the 'features'. >> 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 -- You and me both... it didn't look like a mistake then, but after trying to use it for a little while BOY was it a mistake! -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA