home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 3059 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  2.5 KB
  1. Xref: sparky comp.object:3059 comp.lang.eiffel:1021
  2. Newsgroups: comp.object,comp.lang.eiffel
  3. Path: sparky!uunet!psinntp!merlin.hgc.edu!jcm
  4. From: jcm@hgc.edu (James McKim)
  5. Subject: Re: Class methods (was: Re: How to design a data structure library)
  6. Message-ID: <1992Jul29.140357.26748@merlin.hgc.edu>
  7. Sender: usenet@merlin.hgc.edu (Action News Central)
  8. Organization: The Hartford Graduate Center
  9. References: <1992Jul27.155428.11825@bony1.bony.com> <graham.712283419@galois> <1992Jul28.201820.27793@bony1.bony.com>
  10. Date: Wed, 29 Jul 1992 14:03:57 GMT
  11. Lines: 63
  12.  
  13. In article <1992Jul28.201820.27793@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:
  14. >In article <graham.712283419@galois> graham@maths.su.oz.au (Graham Matthews) writes:
  15. >
  16. >[...]
  17. >
  18. >>
  19. >>Are you really serious about this notation Richie? This means that
  20. >>I would have to write integer addition as
  21. >>
  22. >>    !!c.+(6,7);
  23. >>
  24. >>After all it creates a new integer!
  25. >>
  26. >
  27. >It's not the notation that I'm arguing for. 
  28. >
  29. >!!c.+(6,7) is certainly awful syntax. But, (as Jim McKim suggested in
  30. >private e-mail) couldn't the compiler do the translation from c := 6 +
  31. >7; to the above monstrocity.
  32.  
  33. Well, before I get flamed too badly for the above suggestion, let me
  34. say that I haven't fully thought it out. I think the compiler would
  35. have to be smart enough _not_ to make the above translation in the case of 
  36. simple integer arithmetic.
  37.  
  38. >
  39. >My point is that certain methods, "+" for example, should be class
  40. >(i.e. creation) methods.
  41.  
  42. Yes, it's really the design of the _class_ that originally sparked
  43. this discussion, not the syntax used. It does seem that designing
  44. the standard set operations, string operations, etc as creation
  45. routines is an idea worth pursuing.
  46.  
  47. >
  48. >However, once you get away from numbers, with their historical
  49. >notation, things make more sense. How about a "concat" method on
  50. >strings. We'd have:
  51. >
  52. >           !!s.concat("foo", junk);
  53.  
  54. People will argue that this could be written as either
  55.         s := "foo" + junk         a la Turbo Pascal or
  56.         s := "foo" concat junk  
  57.   
  58. If we can get the compiler to translate the latter two into the
  59. former, we can have our simple syntax and our clean design, too.
  60. But again, I don't know how smart the compiler would have to be
  61. in order to accomplish this.
  62.  
  63. >
  64. >
  65. >
  66. >...richie
  67. >
  68. >-- 
  69.  
  70. -- Jim
  71. -- 
  72.  
  73. *------------------------------------------------------------------------------*
  74. Jim McKim  (203)-548-2458     In exactly 3.2 seconds it will be a few 
  75. Internet:  jcm@hgc.edu   minutes to 5:00.
  76.