home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19748 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  4.4 KB
  1. Xref: sparky comp.lang.c++:19748 comp.object:4996
  2. Newsgroups: comp.lang.c++,comp.object
  3. Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!bernina!neptune!santas
  4. From: santas@inf.ethz.ch (Philip Santas)
  5. Subject: Re: Pros and cons of C++
  6. Message-ID: <1993Jan22.142518.22644@neptune.inf.ethz.ch>
  7. Sender: news@neptune.inf.ethz.ch (Mr News)
  8. Nntp-Posting-Host: ru3.inf.ethz.ch
  9. Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
  10. References: <1993Jan21.144542.20593@midway.uchicago.edu> <1993Jan21.200817.10226@neptune.inf.ethz.ch> <1993Jan21.231618.8962@midway.uchicago.edu>
  11. Date: Fri, 22 Jan 1993 14:25:18 GMT
  12. Lines: 75
  13.  
  14. In article <1993Jan21.231618.8962@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:
  15. > santas@inf.ethz.ch (Philip Santas) writes:
  16. >>
  17. >>Since in C++ you _cannot_ redefine primitive operations with means
  18. >>other than macros (and we were not talking about macros), nothing of the
  19. >>problems you mention occur. Notice that equalty on integers, for instance,
  20. >>cannot be redefined. The reason it cannot, is that int is not a class;
  21. >>you can redefine operators only in classes.
  22. >>
  23. >
  24. >You have asserted that this is not a problem in languages in which primitives
  25. >are classes (Smalltalk, Axiom/Scratchpad).  The problems I discussed are
  26. >still present in those systems.  C++'s (IMHO) inconsistent design decision to 
  27. >treat primitives as non-class types is hardly a point in it's favor.
  28.  
  29. What I said is that you cannot redefine the primitives, and I gave you
  30. the reason why. I have never said that this separate treating is of any
  31. language's favour. (you definitely have a way of "inventing" statements
  32. and atribute them to other people :-(  )
  33.  
  34. >>I understand that you want to substitute a symbol, say "=", with one value
  35. >>all over your formalism, but the fact that you cannot do it, does not mean
  36. >>that the language is complex, it means that you have to find another way
  37. >>to deal with it. Furthermore, people feel comfortable with operators
  38. >>like "+" and "*" which have been primitevely overloaded for reals, integers, 
  39. >>etc. There is no reason why not to treat "=" in the same way.
  40. >
  41. >If you've still got the archive, the value/object discussion of a month 
  42. >ago makes my position pretty clear on this subject, in probably overly
  43. >deep detail. 
  44.  
  45. To what extend has this been covered by the object/value discussion?
  46.  
  47. >>Notice also that we deal with a non-trivial type system (I do not discuss
  48. >>how it is implemented, this is another story)
  49. >>Denotational semantics have elegant approaches on simple type systems,
  50. >>but for more complicated ones they are confusing. Notice that by
  51. >>assuming _traditional_ subclassing, you have a form of overloading "=",
  52. >>since the objects have (od do not have) to coerce to the superclasses
  53. >>in many cases. This overloading occurs with every link you add.
  54. >
  55. >Nonsense.  In traditional subclassing, there is no concept of coercing to
  56. >the superclass at all.  Coercions, if they occur, are utterly orthogonal to
  57. >the subclassing heirarchy.  C++ implements this _very_ poorly (truncating
  58. >objects if passed by value!) but calling this traditional inheritance is
  59. >just wrong.
  60.  
  61. I hope you are familiar with the terms "reference semantics" and "value semantics".
  62. Coercions do occur when you move the object to the superclass in "value semantics".
  63. Are you saying that traditional subclassing does not involve values?
  64.  
  65. Furthermore, you definitely coerce an object when you move it to the superclass,
  66. since you alter its behaviour. If you don't believe me, make equality tests
  67. on objects of differnt classes (which are at the same inheritance path).
  68.  
  69. >As much as I would love to spend the next decade (a conservative estimate)
  70. >working on a formal definition of C++, I'm forced to pass.  Even suggesting 
  71. >that someone might need to put in that huge amount of work to prove this 
  72. >utterly trivial point weakens your case.
  73.  
  74. "trivial point" = "I don't know how to prove it" :-(   
  75. Right?
  76.  
  77. Philip Santas
  78.  
  79.   "In an evolving universe those who stand still are really moving backwards"
  80. --------------------------------------------------------------------------------
  81. email: santas@inf.ethz.ch                                Philip Santas
  82. Mail: Dept. Informatik                     Institute of Scientific Computation
  83.       ETH Zurich                          Swiss Federal Institute of Technology
  84.       CH-8092 Zurich                                  Zurich, Switzerland
  85.       Switzerland
  86. Phone: +41-1-2547478
  87.       
  88.  
  89.