Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!akl From: akl@mentor.cc.purdue.edu (Rob Tillotson) Newsgroups: comp.sys.amiga Subject: Re: Objective C is a Kludge ( was Re: An Intuition.device? ) Message-ID: <14010@mentor.cc.purdue.edu> Date: 14 Sep 90 23:26:29 GMT References: <1032@ucsvc.ucs.unimelb.edu.au> <90255.124203UH2@psuvm.psu.edu> <385@public.BTR.COM> <1990Sep14.091728.10447@evax.arl.utexas.edu> Reply-To: akl@mentor.cc.purdue.edu (Rob Tillotson) Organization: Who ya gonna call? CloneBusters! Lines: 63 In article <1990Sep14.091728.10447@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Col. Ames and Pixel) writes: > > I vote we trash C, C++,Ob-C (OB-Gyn's brother) and Power Windows/IB >tools and go for Resources like exist in OS/2 and the Mac. With that a "User >Interface" paint program becomes piece of cake. It seems to me that discarding the idea of object oriented development tools simply because resources exist is a bad idea, since resources do not provide all of the advantages the tools you mention do. In fact, the idea of resources meshes much more easily in a system with an object oriented user interface, and lend an object-oriented flavor to "typical" programming styles: with user interface elements stored as resources, programs can then deal with encapsulated objects instead of raw data structures. In fact, in a fully resource-driven system, a program (or programmer) might never know or care what is really inside a "Window" or "Gadget" resource, except that it can be edited by a resource editor and placed on the screen with a simple function call or two. This is one of the fundamental ideas in object- oriented programming... Actually, in a fully object-oriented user interface, "resources" will probably exist simply because it would be very inconvenient to do without them. An example would be Objective-C and Interface Builder on the NeXT. Interface Builder lets you edit and create predefined user interface objects, causes them to be linked into a special segment of your program. In the program, you simply refer to them by name, and they are automatically loaded when needed. Later, you can use IB to edit those objects - move windows and buttons around, change text, rearrange menu items, whatever - and the program doesn't need to be recompiled. At a very basic level, ResEdit (and its counterpart in OS/2, whatever it's called) is sort of like an ancestor of IB - the two environments are quite different, but the basic idea is there. So I guess what I am saying is that resources and object oriented development tools are not mutually exclusive, and in fact something akin to resources is a useful (and maybe even necessary) part of an object oriented user interface. Adding resources to a traditional environment does give significant benefits, but that is no reason to not take the next step and add a more powerful interface building tool and an object oriented language. > This would probably have to wait till CBM comes out the "incompatible" OS >release since it is linked into the executable. If done properly one could add >as much as you want in this area, since all external references are resolved by >the linker. It wouldn't necessarily have to wait for a new OS. You can paste resources onto an existing executable in a way the linker will ignore, then write a small library to load them. Or even put them in a separate file, although that might be a bit inconvenient in some cases. Of course, the difficult part is making the tools to deal with them... a resource editor, for example. So, even though an OS-supported resource system would be a big plus, it is certainly possible to beneifit from some of the advantages of a resource system or even object oriented user interface without one. Obviously the tools have to exist, but they don't have to be part of the OS... G'day, eh? --TS -- Rob Tillotson Internet: akl@mace.cc.purdue.edu 400 N. River Rd. #1418 BITNET: ROBT@PURCCVM West Lafayette, IN 47906 Fido: 1:201/40.302