🚀 go-pugleaf

+-- pds@quintus.UUCP (Peter Schachte) writes:
| shf@well.UUCP (Stuart H. Ferguson) writes:
| > How about a "filerequester.library?"
| 
| In article <> mp1u+@andrew.cmu.edu (Michael Portuesi) replies:
| >How about instead of a "filerequester.library", we create a shared
| >library named "intuitiontools.library", which contains some high-level
| >user interface tools for intuition.
| 
|  [...] By putting everything in one
| library, you either restrict its scope or burden the whole system with
| lots of code in memory when only a small part is needed.  Putting
| everything in one place (or few places) makes it painful to replace
| several parts of the system.

My reasoning exactly -- that's the purpose of putting the requester in
a library by itself.

| I think a better way to organize these things would be objects
| (classes).  A program would just create objects and send messages to
| them.  The methods (messages implementations) would be kept in something
| much like a library, and each actual instance would keep a pointer to
| its library.

This is a neat idea which I've been thinking about for a while now.
There are several problems, technical and social.  The technical problems
revolve around selecting a message-passing scheme.  My first thought
was to use the library structure itself as a dipatch table to 
enumerated methods.  This is very fast since all "messages" are really
just library calls at hard-coded offsets.  It's limited, however, in
that classes are strictly hierarchical and methods have to be nested.
Another approach would be to use symbolic message codes and have each
"message" to an object involve some sort of string or ID which would
be searched for by the object and passed on if unrecognized.  This is
not nearly as fast and is a lot more complex, but it is fully general
with regards to building subclasses and extending your superclasses. 
This scheme can be made fast, but at a price of complexity.
It also has a giant global namespace which I'm not so hot about.

Any ideas on that Peter?

The social problem is making it catch on.  I suppose if it is
useful enough people would use it, but for commercial applications ...
It's actually the social concerns that have me suggest a filereq.
library.  a) It can be done reasonably quickly. b) It's small and
unobtrusive -- you don't have to buy a whole philosophy to use it.
c) It encuurages the gifted "utility" writers to make their own.
d) If widely used, it shows off the advantage of having your application
broken up into lots of little cooperating bits.  (Once that idea is
sold, it's easier to sell a full-blown O-O system.)

Oh well, I'll leave the social aspects to another group -- this is
comp.sys.amiga.TECH!
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC