Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!eris.berkeley.edu!mwm From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: Standard File Requesters Message-ID: <24769@agate.BERKELEY.EDU> Date: 23 May 89 21:46:22 GMT References: <0914.AA0914@amigash> <941@sactoh0.UUCP> <11583@well.UUCP> <1051@quintus.UUCP> <11636@well.UUCP> <3828@amiga.UUCP> Sender: usenet@agate.BERKELEY.EDU Reply-To: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) Distribution: na Organization: Missionaria Phonibalonica Lines: 65 I give up - I've been trying to catch up before commenting, and not getting anywhere. So let's answer a question of Jimm's, and then give my (right, of course :-) answer to the question of UI libraries In article <3828@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: < Making little extensions to large classes is what leads people to such < odious things as "multiple inheritance." I figure if I read some more < of those damn journals, there'd be some alternatives to inheritance < which still give you polymorphism (the ability to say: "Delete You" < without knowing to whom). I think you're talking about "mixins" (name from the flavors system, of course). You create a class (say window), and it gets to use mixins (borders, scroll bars, etc). Think of them as "not-quite-classes" that you can multiple-inherit from. I haven't explored all the variations (running from "each class has it's own mixins" through multiple inheritance), but somewhere in there there ougtha be an answer. Now, for my suggestion in the UI area. What we really need is _two_ levels. A components level, and an objects level. The components would be a library that provides simple gadgets/requesters/etc, all with the same look (and feel?). Up-arrow, down-arrow, string (either text or numeric) requesters, one & two-d sliders, even the ever-popular "scrolling text box" gadget (calling itself, of course). Call this "components.library" or some such. On top of this, we build _real_ objects. Requesters and other things, or libraries of them. You have "requesters.library" which includes the common requesters: files, color requesters, devices, anything else you can think of. These are built of components from the components library. Both should have well-defined interfaces. You can change the looks (and some of the feel) of your requester at will by changing the components library - but it will still have the same basic layout and behavior. You can change the layout and behavior by changing the requesters library - but all the components will still look (and act) the same. In addition, if a program rolls it's own requesters from the components library, they still come up looking (and acting, to some degree) like the standard requester types. I've got load libraries that do part of this, for menus & requesters. They work, and I use them. But I don't do enough intuitionified stuff to warrant completing them and turning them into real libraries. Also, I just tossed the file requester in with the rest of the requesters library; not much point in seperating it out of load libraries. The problem, of course, is deciding just where to put the line between the "components" and the "requesters" (or "windows" or whatever) libraries. Like the "mixins" problem, finding the right point is critical for making it a success. As for making it a social success, I can only see two ways: 1) give it away so everybody can use it, and charge developers bucks for support and documentation, or 2) get CBM to put it in 1.4 (or whatever). And #2 has a lot better chance of working than #1.