home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / oop / macapp3 / 629 < prev    next >
Encoding:
Text File  |  1993-01-27  |  2.6 KB  |  51 lines
  1. Newsgroups: comp.sys.mac.oop.macapp3
  2. Path: sparky!uunet!pageworks.com!world!eff!news.byu.edu!gatech!paladin.american.edu!howland.reston.ans.net!spool.mu.edu!sdd.hp.com!decwrl!csus.edu!netcom.com!knee
  3. From: knee@netcom.com (Mark Lanett)
  4. Subject: Re: Re2: C++ (was re: bedrock defe
  5. Message-ID: <1993Jan28.013214.26233@netcom.com>
  6. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  7. References: <728150543.6883842@AppleLink.Apple.COM>
  8. Date: Thu, 28 Jan 1993 01:32:14 GMT
  9. Lines: 40
  10.  
  11. ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT) writes:
  12.  
  13. >You wouldn't have to remove features, just design them to coexist better.  For
  14. >example, if you overload a function and then override one instance of it, all
  15. >of the other instances get hidden.  Why not allow these featues to coexist
  16. >instead of conflict.
  17.  
  18. The "hiding" *is* a feature, provided so C++ can warn you about covariant
  19. relationships, on the theory that overriding one function but not its
  20. siblings is more likely to be a logical error. You are free to provide
  21. pass-through overrides of the siblings if it applies to your situation.
  22.  
  23. >Changing the default would improve reliability without having to impact
  24. >performance.  All a programmer would have to do to get the performance would be
  25. >to explicitly declare critical methods as nonvirtual.
  26.  
  27. Or use an intelligent DevEnv like Component Workshop. A lot of C++ stupidities
  28. have more to do with the need to parse it as text and compile it without knowing
  29. what context it's going to be used in. As we climb out of the text-based
  30. DevEnv hole, the language will be able to evolve to take advantage of
  31. information provided by the development environment.
  32.  
  33. >I agree that stack-based objects are usefull.  However, I don't think they are
  34. >quite the same thing as a class and could be restricted to structs.  Doing this
  35. >would allow class to be changed to have virtual for its default (or even
  36. >better, have no default).
  37.  
  38. Heh, never tried resource acquisition? If MacApp had real exception handling
  39. you'd see a LOT of stack-based classes for that purpose. It would do away
  40. with almost all FailInfo clauses that exist in your code today. That's a
  41. real plus.
  42.  
  43. >I don't think any of these changes would this would impact the power of C++,
  44. >but would make it less error prone and easier to learn.
  45.  
  46. How do stack-based objects make C++ harder to learn? The only situation I
  47. can think of is declaring one with the parenthesis for a default
  48. constuction (i.e. "CFoo f();") which instead declares a function returning
  49. such an object. It results in a compile-time error anyway, so all you need
  50. is a compiler that provides an intelligent error message in that case.
  51.