🚀 go-pugleaf

ede978e@monu6.cc.monash.edu.au (Robert D. Nicholson) writes:
>If you have some time, give this one a shot.

  Sure ... I will, however, keep my points to the realms of ObjC, C++, NeXT
and X since those are the OOPL/UIs that I am most familiar with.  All of
this is IMHO.  If your a C++/X lover, beware -- I'm not.  Those who wish to
correct me by stating that X is not a UI but a graphics protocol may
refrain from doing so.  I like Display Postscript anyway (which X is
attempting to use now ... snicker, snicker).


>Why would you rather develop a GUI application using OOP than using 
>a structured language like C?

  First, note that OOP doesn't exactly imply non-structured.  ObjC is a
good example of how OOP/structured programming can interact.
  Anyway... I find that OOP is good for GUI programming for the following
reasons, among others.

  (1)  Standarization of an interface across a platform.  Regardless of what
  a number of people say, customizable interfaces are not all that they are
  cracked up to be.  A standardized interface cuts the time needed to learn
  an program.  Richard Stallman (in a talk at the University of Washington,
  in reference to interface infringement lawsuits) described this with the
  example of the steering wheel/clutch/brake/accelerator of a car.  This is
  a good interface.  It is standardized.  Wouldn't we all have a beastly
  time if it weren't.  Standardization also allows you to write a fairly
  small/dependable/fast window manager since to don't have to worry about
  which of the N custom settings some user is going to use.

  (2)  Its easier.  Even if you don't use a product like IB, it is fairly
  easy to set up your own interface objects in code.  At least this is true
  on the NeXT.  I wouldn't want to speculate on XView since it has two basic
  problems, C++ and X.

>What benefits/problems do you see in using OOP ?

  (1)  The obvious: reusability of code in terms of both subclassing them
  and being able to use them in lots of places due to the seperation
  between interface and implementation.  Seperation of client/server with
  no fuss.

  (2)  OOP almost forces you to come up with a good design, or at least a
  better one (in terms of understandability) than you would with an non-OOP
  language.  This is not saying that you can't make a nice design in a
  non-OOP language, but if the program is more complex than a while loop,
  it will almost invariably happen that the code looks either OOPesque or
  like some functional language (say LISP). 

  (3)  There aren't enough standardized objects yet.  OMG is working on
  this, though (with NeXT as the major contributor).

  (4)  C++.  Yuck.  It doesn't even have an ANSI standard yet but everyone
  and their anteater is using it.  One might argue that ObjC isn't
  standardized yet either, but then again, you can describe the differences
  between ANSI-C and ObjC in 30 pages (this is how long the NeXT ObjC manual
  was under 1.x/2.x ... haven't seen the 3.0 one yet but they haven't added
  a whole lot).  In comparision, my copy of 'The Annotated C++ Reference
  Manual (ANSI Base Document)' (Ellis/Stroustrup) is 407 pages.  And these
  are all very *ugly* pages.  The 2nd Ed 'The C++ Programming Language'
  (Stroustrup) (*Why* is is using this title?  He is not a K nor an R, but
  an S!)  quite a bit easier to read, but at the expense of an even longer
  text.  Multiple inheritence is evil.  Protocols are *much* cleaner (NeXT
  ObjC under 3.0)  C++ doesn't have calltime binding of methods, or even a
  generic object type.  How could anyone expect to get much benifit from
  object polymorphism without calltime binding?  How many *compilers* (not
  C++ -> C front ends) are there?  One that I know of: g++.  And I doubt
  that even FSF implemented all the features of C++.  I haven't heard of a
  compiler *or* translater that implements templates.  Of course this is
  because they don't have a generic object type or calltime binding.
  I guess that's enough flagellation of the deceased equine.
    I'm very much relieved that FSF is finally getting their ObjC runtime
  ready.  Perhaps this will slow down (and even reverse??  Oh Please let it
  be!) the spread of C++.  At a minimum, it will force the C++ community to
  clean up their language (wash their mouths out with soap, we will!)
  Ok.  That's really enough now.  I think.  Maybe.

>How do you feel the use of a UIMS (IB) helps ?

  (1)  No code.  All you have to do is drag the pieces of your interface
  where you want them and connect them.  On the NeXT, you can even test
  your interface *without* compiling.  IB will even let you deisgn you own
  palettes of UI objects.

  (2)  No code!  You can see exactly what your interface is going to look
  like.  You don't have to sit down with graph paper and figure out a bunch
  of numbers to describe your interface.

  (3)  NO CODE!  If you wan't to change your interface five times a day, no
  problem.  It only took you two minutes to set it up in the first place.


Tim Wood
The Omni Group