Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!sun!quintus!pds From: pds@quintus.UUCP (Peter Schachte) Newsgroups: comp.sys.amiga.tech Subject: Re: Standard File Requesters Message-ID: <1051@quintus.UUCP> Date: 10 May 89 22:48:52 GMT References: <0914.AA0914@amigash> <941@sactoh0.UUCP> <11583@well.UUCP> Reply-To: pds@quintus.UUCP (Peter Schachte) Distribution: na Organization: Quintus Computer Systems, Inc. Lines: 44 shf@well.UUCP (Stuart H. Ferguson) writes: > How about a "filerequester.library?" In article mp1u+@andrew.cmu.edu (Michael Portuesi) replies: > Graphical UI != File Requester in a Library True. MUCH MUCH more is needed. Stuart didn't go far enough. >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. But you're not going far enough, either. 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. For example, you may want someone's scroll bars, someone else's file requesters, someone else's popup pie menus, etc. If these thing are kept separate, rather than all stuffed into a single library or a few, then it would be much easier to pick and choose. 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. Then, just by replacing the library, you would change the implementation of a class. Also, inheritance would be really helpful, since, e.g., by replacing the ScrollingWindow class you would change scrolling behavior for subclasses of ScrollingWindow as well. Another really intriguing aspect of this approach is that many applications would mostly be implemented as classes. The main program would just create a few objects and send them some messages. If the object system itself supplied code for handling the event loop, as does Xtk and Sunview and others, the main program could just exit, leaving the object system to handle things from there. You could spawn as many editors as you want, you'd still only have one process handling them, and all code would be shared. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds