eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) (09/13/90)
In article <90255.124203UH2@psuvm.psu.edu> UH2@psuvm.psu.edu (Lee Sailer) writes: [ ... ] >When you are finished, IB creates the Obj-C source code (an OO dialect of >C--much more elegant than C++ but more differnet from regular C) that will >generate the interface you just designed.... >Footnote. While not as widely used as C++ or Smalltalk, Obj-C seems like >a really good way to go, especially since it is sort of the core language of >NeXT. With some sort of interface layer between NeXTSTeP and Intuition, >I can even imagine NeXT applications porting easily to Amiga 3000. Objective C is a hybrid of C and Smalltalk. It has a full set of C for writing routines, and something akin to Smalltalk's message passing system. It uses a fully tagged system to send messages. This is not a bad thing, it just requires a lot of writing and keeping track of tags. All of the objects also located on the heap, leading to memory fragmentation. Objective C does not have operator overloading (something I find indespensible in C++) but also not a temendous flaw. (* HERE COMES! *) However, Objective C does not have constructors or destructors, and that makes it unacceptable as a true OOPL. Finally, Objective C only has dynamic typing (slow). For these reasons, especially execution speed (Amigas don't come with standard 25MHz '030's) that I don't think Objective C is the ideal language for the Amiga platform. C++ has the advantage of static binding and execution speed, while Smalltalk has the advantage of a single paradigm. What we should be looking for is a language that combines the execution speed of C++ with the structure of a pure OOPL like Smalltalk. Just my opinions. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I know what I'm doing." - Sledge Hammer =========================================================================
new@ee.udel.edu (Darren New) (09/13/90)
In article <385@public.BTR.COM> eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) writes: >However, Objective >C does not have constructors or destructors, and that makes it unacceptable >as a true OOPL. Say what!?! Smalltalk does not have destructors either, but I wouldn't say that makes Smalltalk not a OOPL. (I think it should have destructors, but then you get back to reference counting, which is also slow.) >Finally, Objective C only has dynamic typing (slow). Not true. My understanding is that Obj-C is a strict superset of plain old C, and hence has plenty of static typing. The dynamic function calls should not be particularly slow either, judging by what I know of their implementation. Certainly not much slower than C++'s virtual functions, if indeed slower at all. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee -----
eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) (09/14/90)
In article <385@public.BTR.COM> I wrote: >>Finally, Objective C only has dynamic typing (slow). In article <30261@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: >Not true. My understanding is that Obj-C is a strict superset of plain >old C, and hence has plenty of static typing. In the C part maybe, but whenever an object is involved, the dynamic typing comes into effect. Objective-C consists of two separate mutually distinct languages, shall we say. The C stuff does all of the grunt work, while an objective part handles message passing. The C stuff is plain C, no overloading, etc. like C++. The objective part looks a little like Smalltalk or BOOPSI. Both are distinct. Sending the (obviously) wrong message to an object results in a run-time error. Sure you can write a program that doesn't have dynamic typing, but then you aren't using the objective part of Objective-C. >The dynamic function calls should not be particularly slow either, >judging by what I know of their implementation. Certainly not much >slower than C++'s virtual functions, if indeed slower at all. Agreed, but Objecctive-C doesn't use function calls to invoke methods. It sends messages. I'm not saying that I don't want to see a package that produces Objective-C style intuition code, what I'm saying is that I don't really want to see that become the *standard* Amiga development environment. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I know what I'm doing." - Sledge Hammer =========================================================================
hill@evax.arl.utexas.edu (Col. Ames and Pixel) (09/14/90)
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.
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.
What do the rest of you think of this???
--
adam hill Everybody lies about sex.
hill@evax.arl.utexas.edu BOING!4Ever Rub HER feet!
It's better to copulate than never
AmigaDos2.0 - A VW with $10,000 in options. --Robert A. Heinleinnew@ee.udel.edu (Darren New) (09/14/90)
In article <389@public.BTR.COM> eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) writes: >>The dynamic function calls should not be particularly slow either, > Agreed, but Objecctive-C doesn't use function calls to invoke >methods. It sends messages. And the messages are looked up via a hash table and are turned into a call on a function. Of course Objective-C uses function calls to invoke methods: it compiles into C, and C only has functions. Just like C++ turns a message (i.e., virtual function call) into a function call through an indirect pointer. The only slow-down in Obj-C is running up the inheritance heirarchy, which I understand has been optimized very well in the later versions. --Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee -----
akl@mentor.cc.purdue.edu (Rob Tillotson) (09/15/90)
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
eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) (09/15/90)
In article <30465@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: >In article <389@public.BTR.COM> I wrote: >>>The dynamic function calls should not be particularly slow either, >> Agreed, but Objective-C doesn't use function calls to invoke >>methods. It sends messages. >And the messages are looked up via a hash table and are turned into a call >on a function. Of course Objective-C uses function calls to invoke methods: >it compiles into C, and C only has functions. Just like C++ turns a message >(i.e., virtual function call) into a function call through an indirect pointer. >The only slow-down in Obj-C is running up the inheritance heirarchy, which >I understand has been optimized very well in the later versions. --Darren [ sig deleted ] But C++ only uses a call through an indirect pointer from a table if virtual functions are used. I have found that virtual functions and polymorphic objects are seldom used, and can usually be worked around. When virtual functions are not called through a pointer to an object, C++ uses either a standard C function call or no function call at all for inline functions. Now if you do this once or twice, there is very little difference noted in execution times. However if you are sending several thousand messages each second, say using a file requester with a hot scroll bar, a few microseconds per call begins to add up. I am a strong believer in the theory that any computations that can be done at compile time should be done at compile time rather than at run time. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I know what I'm doing." - Sledge Hammer =========================================================================
ifarqhar@mqccsunc.mqcc.mq.oz.au (Ian Farquhar) (09/16/90)
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. > > 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. > > What do the rest of you think of this??? Resource scripts, it seems to me, have a good side and a down side. The down side is that a resource script requires a (hopefully) small amount of time to interpret, and thus is a source of inefficiency. I would hope that the standard C interface would be maintained, with the resource manager (presumably part of the asl.library) as an additional shell over it. The argument that they ease programming does not stand close examination. Tools for generating interfaces can be quite efficiently written without resource scripts, and a decently designed one could read its own code back again. In fact, the only convincing reason I can see for resource scripts is that it would allow an editor to manipulate the look of the program. I am so sick of those dog-ugly amiga programs (I could name a few), and if I could get in there with a resource editor (such as the excellent resedit on the Mac), I could certainly do things to improve this. However, as a programmer, supporting such a system would be difficult. Who would want to support a product where the inexperienced user could remove important menu items or buttons, or where rogue copies of these cutomised programs could be distributed? This is a very interesting discussion about which I would like to hear other opinions. -- Ian Farquhar Phone : 61 2 805-7420 Office of Computing Services Fax : 61 2 805-7433 Macquarie University NSW 2109 Also : 61 2 805-7205 Australia EMail : ifarqhar@mqccsuna.mqcc.mq.oz.au
hill@evax.arl.utexas.edu (Col. Ames and Pixel) (09/17/90)
In article <522@macuni.mqcc.mq.oz> ifarqhar@mqccsunc.mqcc.mq.oz.au (Ian Farquhar) writes: >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. Sorry, I didn't want to say we should throw away Object Oriented languages, but that resources should be INTEGRATED (key word) with a language or that it should be designed to interface well with several languages. I envision something like this: D&DEditor.resource TYPE Window { CLASS Normal; PARAMS 15,20 hires, maxoverscan, drag, resize, fb, minmax; CONTROLS Button1, NormalButton "PushME", Sysdraw; CONTROLS Button1, HelpButton, HelpOn(MenuPick, RegionPick, Gadget) HelpKey (F1), "Press for Help", Sysdraw, SysHandleIt } Etc..... Resources would need to have a binding to something else so you couldn't just modify it and it would work with the changes. Like a resource compiler that OS/2 uses. I would use a resource like a 'set of objects'. You could have TYPE's of Buttons that have "predefined" actions. Windows that could be Normal, Genlock Inputtable (sp?), PutLaserDiscOutputHere.... And the resource language would be able to "build" gadgets. you could import a IFF of a spedometer and use graphic primatives to draw a needle or perhaps attach 1 character TEXT fields to them and change them. This might necessitate a .gadlib type of file to keep from having to recompile old gadgets over and over again. You should also be able to build window TYPES that will always have a Listbox ands 4 Buttons with "xxxx" in each. Especially DIRECTORY, FONT PALLETE TYPES should be done and with "configurability". If I wanted a PALETTE requestor with CYMK in there and HAM "color spread" to pick from , along with a predefined set of colors in a requestor I could do it. Perhaps this is a bit on the compilcated side, but it could be done. I would first decide on the level of control, perhaps building gadgets is a bit much at first. And in the way I envsion it i would like Inuition support as well. >However, as a programmer, supporting such a system would be difficult. >Who would want to support a product where the inexperienced user could >remove important menu items or buttons, or where rogue copies of these >cutomised programs could be distributed? > >This is a very interesting discussion about which I would like >to hear other opinions. Me too!! I would like to hear from the Mac side... I already know about the OS/2 side. >-- >Ian Farquhar Phone : 61 2 805-7420 >Office of Computing Services Fax : 61 2 805-7433 >Macquarie University NSW 2109 Also : 61 2 805-7205 >Australia EMail : ifarqhar@mqccsuna.mqcc.mq.oz.au -- adam hill Everybody lies about sex. hill@evax.arl.utexas.edu BOING!4Ever Rub HER feet! It's better to copulate than never AmigaDos2.0 - A VW with $10,000 in options. --Robert A. Heinlein