home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / oop / macapp3 / 616 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  2.7 KB
  1. Path: sparky!uunet!scifi!acheron!philabs!linus!agate!stanford.edu!apple!applelink.apple.com
  2. From: ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re2: C++ (was re: bedrock defe
  5. Message-ID: <728150543.6883842@AppleLink.Apple.COM>
  6. Date: 27 Jan 93 15:54:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 48
  10.  
  11. Larry,
  12.  
  13. >You're right about this, and I haven't considered these issues.  The == vs.
  14. >= problem is a flaw that C++ inherits from C.  The same is true of switch
  15. >statements (where leaving out the break in each case is usually a mistake).
  16.  
  17. There are other examples that cannot be blamed on C.  One is the lack of a key
  18. word when overriding or overloading a method.  This would give a safty check
  19. that you havn't made a mistake in your method name.
  20.  
  21. Another example is the lack of the key word inherited.  This allows your code
  22. to automatically adapt as your superclasses evolve.  As it stands now, if you
  23. insert an override, it may never get invoked and you will not get any kind of
  24. indication from the compiler.  Fortuanatly, C++ allows you to write
  25. superclassname::methodname() to get the effect of inherited.  However, even
  26. then, if you change your superclass, you will have trouble.  In any other OO
  27. language I'm aware of, you would have used either inherited or super originally
  28. and never run into a problem.
  29.  
  30. >> like having various features clash when used together or having the wrong
  31. >I think there's a tradeoff here.  You could remove lots of features from
  32. >the language, but then there would be useful things that you couldn't do.
  33.  
  34. You wouldn't have to remove features, just design them to coexist better.  For
  35. example, if you overload a function and then override one instance of it, all
  36. of the other instances get hidden.  Why not allow these featues to coexist
  37. instead of conflict.
  38.  
  39. >> defaults when using features (why isn't virtual the default?).  It's a shame
  40. >C++ was designed for maximum performance.
  41.  
  42. Changing the default would improve reliability without having to impact
  43. performance.  All a programmer would have to do to get the performance would be
  44. to explicitly declare critical methods as nonvirtual.
  45.  
  46. >For example, removing stack-based objects would simplify things
  47. >considerably, but stack-based objects are useful in many places.
  48.  
  49. I agree that stack-based objects are usefull.  However, I don't think they are
  50. quite the same thing as a class and could be restricted to structs.  Doing this
  51. would allow class to be changed to have virtual for its default (or even
  52. better, have no default).
  53.  
  54. I don't think any of these changes would this would impact the power of C++,
  55. but would make it less error prone and easier to learn.
  56.  
  57. Alan
  58.  
  59.