home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / objectiv / 526 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  6.6 KB

  1. Path: sparky!uunet!wupost!sdd.hp.com!swrinde!zaphod.mps.ohio-state.edu!n8emr!uncle!oink!count0!cgb
  2. From: cgb@count0.cmhnet.org (Charles G. Bennett)
  3. Newsgroups: comp.lang.objective-c
  4. Subject: Re: General OOP Question
  5. Message-ID: <1992Sep9.124125.1555@count0.cmhnet.org>
  6. Date: 9 Sep 92 12:41:25 GMT
  7. References: <1992Sep8.164922.11325@u.washington.edu>
  8. Sender: cgb@count0.cmhnet.org
  9. Reply-To: cgb@count0.cmhnet.org
  10. Organization: BenaTong
  11. Lines: 129
  12.  
  13. In article <1992Sep8.164922.11325@u.washington.edu>  
  14. bungi@carson.u.washington.edu (Timothy J. Wood) writes:
  15. > ede978e@monu6.cc.monash.edu.au (Robert D. Nicholson) writes:
  16. > >If you have some time, give this one a shot.
  17. >   Sure ... I will, however, keep my points to the realms of ObjC, C++, NeXT
  18. > and X since those are the OOPL/UIs that I am most familiar with.  All of
  19. > this is IMHO.  If your a C++/X lover, beware -- I'm not.  Those who wish to
  20. > correct me by stating that X is not a UI but a graphics protocol may
  21. > refrain from doing so.  I like Display Postscript anyway (which X is
  22. > attempting to use now ... snicker, snicker).
  23. > >Why would you rather develop a GUI application using OOP than using 
  24. > >a structured language like C?
  25. >   First, note that OOP doesn't exactly imply non-structured.
  26.  
  27. This is to say that a REAL programmer can write FORTRAN programs in
  28. ANY Language.   :-)
  29.  
  30. [munch]
  31. > >What benefits/problems do you see in using OOP ?
  32. >   (1)  The obvious: reusability of code in terms of both subclassing them
  33. >   and being able to use them in lots of places due to the seperation
  34. >   between interface and implementation.  Seperation of client/server with
  35. >   no fuss.
  36.  
  37. Second that.   Ok... Show of hands.   How many times have YOU (the net)
  38. written a Linked List handler?   For me, there has usually been some reason
  39. to re-write it than to go and find the version that, almost, works like
  40. the one I need.   In reality, I used to simply re-write.   In the OBJ-C
  41. would, LIST is a basic class,  I haven't written one since.    But this kind
  42. of re-usability is not restricted to "basic" classes.   I wrote (and sell) 
  43. a Serial Class for the NeXT, that keeps someone from having to learn the UNIX
  44. IOCTLS in order to use the Serial Port's.   I have testimonial letters from  
  45. people who are CLUELESS about UNIX, describing how they used the object.
  46. (High end video deck controllers and virtial lab instruments to name a few.)
  47.  
  48. My point is that not only do you get code re-usability ( I subclassed the
  49. Serial object to create a Mag-Card reader in less than 10 Min's) BUT
  50. you get "Complexity Hiding" and for the first time, once it's written YOU ARE  
  51. DONE.
  52.  
  53.  
  54.  
  55. [munch]
  56. >   (4)  C++.  Yuck.  It doesn't even have an ANSI standard yet but everyone
  57. >   and their anteater is using it.  One might argue that ObjC isn't
  58. >   standardized yet either, but then again, you can describe the differences
  59. >   between ANSI-C and ObjC in 30 pages (this is how long the NeXT ObjC manual
  60. >   was under 1.x/2.x ... haven't seen the 3.0 one yet but they haven't added
  61. >   a whole lot).  In comparision, my copy of 'The Annotated C++ Reference
  62. >   Manual (ANSI Base Document)' (Ellis/Stroustrup) is 407 pages.  And these
  63. >   are all very *ugly* pages.  The 2nd Ed 'The C++ Programming Language'
  64. >   (Stroustrup) (*Why* is is using this title?  He is not a K nor an R, but
  65. >   an S!)  quite a bit easier to read, but at the expense of an even longer
  66. >   text.  Multiple inheritence is evil.  Protocols are *much* cleaner (NeXT
  67. >   ObjC under 3.0)  C++ doesn't have calltime binding of methods, or even a
  68. >   generic object type.  How could anyone expect to get much benifit from
  69. >   object polymorphism without calltime binding?  How many *compilers* (not
  70. >   C++ -> C front ends) are there?  One that I know of: g++.  And I doubt
  71. >   that even FSF implemented all the features of C++.  I haven't heard of a
  72. >   compiler *or* translater that implements templates.  Of course this is
  73. >   because they don't have a generic object type or calltime binding.
  74. >   I guess that's enough flagellation of the deceased equine.
  75. >     I'm very much relieved that FSF is finally getting their ObjC runtime
  76. >   ready.  Perhaps this will slow down (and even reverse??  Oh Please let it
  77. >   be!) the spread of C++.  At a minimum, it will force the C++ community to
  78. >   clean up their language (wash their mouths out with soap, we will!)
  79. >   Ok.  That's really enough now.  I think.  Maybe.
  80.  
  81. No, No, PLEASE continue, and don't forget "Operator Overloading" and "Multiple  
  82. Inhertiance"   Truly the "goto's" of the 90's.   Just think, now you can see a  
  83. statment like   A = B + C and not have the FAINTEST idea why it doesn't work  
  84. :-) or even what Class it belong's to.  There are several large programing  
  85. shops around here that use C++ but do NOT allow the use of either of these  
  86. "Features", since they don't feel that such code can be read or debugged.
  87.  
  88. Let's see if I inherit from an Elephant and a Rhino.. 
  89. I get an Elephino  :-)
  90.  
  91. The problems with C++ are legion, when it comes
  92. to doing truly object oriented programing.    It is, however, good for
  93. doing operating system level stuff.  but then again so is 'C'
  94.  
  95. > >How do you feel the use of a UIMS (IB) helps ?
  96. [munch]
  97. >   (3)  NO CODE!  If you wan't to change your interface five times a day, no
  98. >   problem.  It only took you two minutes to set it up in the first place.
  99.  
  100. Yea, and NO CODE..  With ALL other platforms, what you really have is a "Screen  
  101. Painter"   When your done, it justs barfs out code and away you go.  OH, you
  102. need to change these buttons to check boxes?   Well, if you have already
  103. put your own code in to handle the buttons, you are screwed.  (You'll be
  104. doing it by hand from there on.)
  105.  
  106. With interface builder, you are archiving and unarchiving the REAL, LIVE object
  107. that you'll be using (You CAN'T do this with C++)   the "Target" of, say, a 
  108. button is where you put your own code (really you give the button the id
  109. of your object and the name of the method to call which Interface Builder  
  110. initializes when it un-archives the object.)   That way you can "dink" with
  111. the user interface all day, and as long as you don't "break" the connection to
  112. your object, you don't have to do anything, if you do break it you have
  113. to hold down the control key while you drag a line from the button to an icon  
  114. that represents your object.   Yes Boss, this is HARD WORK.... NOT.
  115.  
  116. I used to try and convert C++ people to "The Way"  now I look on them with
  117. sadness and compassion, while I under bid them by 30% and eat THEIR lunch.
  118.  
  119. They will evolve or become extinct as their lot has decreed.
  120.  
  121.  
  122. Chuck Bennett
  123.  
  124. > Tim Wood
  125. > The Omni Group
  126. -- 
  127. Chuck Bennett, BenaTong Consulting
  128. Harem Security (UNIX Consulting :-) )
  129. cgb@count0.cmhnet.org
  130.