home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3231 < prev    next >
Encoding:
Text File  |  1992-08-17  |  4.0 KB  |  104 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!jvnc.net!yale.edu!ira.uka.de!chx400!bernina!neptune!santas
  3. From: santas@inf.ethz.ch (Philip Santas)
  4. Subject: Re: O.M() versus M(O) notation
  5. Message-ID: <1992Aug17.222621.1099@neptune.inf.ethz.ch>
  6. Sender: news@neptune.inf.ethz.ch (Mr News)
  7. Nntp-Posting-Host: spica.inf.ethz.ch
  8. Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
  9. References: <PCG.92Aug14170701@aberdb.aber.ac.uk> <1992Aug15.124149.28538@m.cs.uiuc.edu> <PCG.92Aug16184526@aberdb.aber.ac.uk>
  10. Date: Mon, 17 Aug 1992 22:26:21 GMT
  11. Lines: 91
  12.  
  13.  
  14. In article <PCG.92Aug16184526@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
  15. >
  16. >johnson> Moreover, I don't think it is fair to complain that someone
  17. >johnson> that uses several of these at once is being inconsistent, he is
  18. >johnson> just blurring the distinction between something and its
  19. >johnson> referent that people always do.
  20. >
  21. >And here we are at one of the crucial points of this discussion. The
  22. >title of this thread is "O.M() versus M(O) notation", and my thesis has
  23. >been that:
  24. >  it makes a lot of difference which notation is used to describe
  25. >  operations on a value
  26. >because the notation strongly influences thought processes and actually
  27. >constrains them (cfr. Dijkstra on BASIC), and that in particular the
  28. >'O.M(...)' notation by making 'O' visually special suggests that
  29. >overloading should happen only on the first argument, which is most
  30. >probably a misleading impression, as overloading resolution ought to be
  31. >symmetrical, which is the most "natural" thing.
  32.  
  33. Although I agree partly with this I have a major dissagreement:
  34. you seem to argue that functions receive more than one arguments.
  35. Well, all my functions receive one argument, and I think that most 
  36. CS scientists and mathematicians agree with this.
  37.  
  38. Since I do not like the O.M(...) syntax and your functions with _many_ arguments, 
  39. I propose you to consider (and comment) the following three cases:
  40.  
  41.  M (O,...)
  42.  
  43. where I have M receiving one argument consisting of an (...+1)-D tuple.
  44.  
  45.  (O,...) M 
  46.  
  47. where I have the tuple object receiving M
  48.  
  49.  O M (...)
  50.  
  51. Where O receives M as argument and
  52. returns another function/object, which receives another argument etc.
  53. The last two cases are much in accordance with OOPs message passing
  54. concept, but are not more than normal functions.
  55.  
  56. >Given this thesis, fuzzy use of the word 'type' is quite a disaster.
  57.  
  58. You produced an artificial example, which, alas, expresses the opinion
  59. of many (missinformed, as you said) programmers of what objects and messages 
  60. are about.
  61.  
  62. >In the case of some languages, like Smalltalk, some of the subsetting
  63. >must be manually implemented by the programmer, in fairly inappropriate
  64. >ways.
  65.  
  66. Can you describe or outline a general purpose method for automatic subsetting?
  67.  
  68. >I am referring for example to deriving a stack class from a deque class;
  69. >one needs to remove from the deque class the (unholy trinity)
  70. >interface/implementation/specification of all the operations that
  71. >operate at one of the two extremes of the deque, but Smalltalk, for
  72. >example, does not allow this.
  73. >
  74. >Yes, one can *simulate* the removal of elements of an interface, for
  75. >example, but this is achieved by redefining an implementation, which is
  76. >quite inappropriate.
  77.  
  78. Concerning specification: I think that subclasses should inherit it as a whole,
  79. otherwise there is no point for making a class subclass of another.
  80. The problem with interface is that current OOPLs do not use functors
  81. for classes, ie. functions which construct new classes out of older ones.
  82. (here I use the term class as you use type. you may freely change the
  83. notation)
  84.  
  85. Philip Santas
  86.  
  87.   "In an evolving universe those who stand still are really moving backwards"
  88. --------------------------------------------------------------------------------
  89. email: santas@inf.ethz.ch                 Philip Santas
  90. Mail: Dept. Informatik                Department of Computer Science
  91.       ETH-Zentrum              Swiss Federal Institute of Technology
  92.       CH-8092 Zurich                       Zurich, Switzerland
  93.       Switzerland
  94. Phone: +41-1-2547391
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.     
  104.