home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 3035 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  2.0 KB
  1. Xref: sparky comp.object:3035 comp.lang.eiffel:999
  2. Newsgroups: comp.object,comp.lang.eiffel
  3. Path: sparky!uunet!walter!geoff
  4. From: geoff@flash.bellcore.com (Geoffrey Clemm)
  5. Subject: Re: Class methods (was: Re: How to design a data structure library)
  6. In-Reply-To: graham@maths.su.oz.au's message of Mon, 27 Jul 1992 23:08:49 GMT
  7. Message-ID: <GEOFF.92Jul28100015@wodehouse.flash.bellcore.com>
  8. Sender: news@walter.bellcore.com
  9. Nntp-Posting-Host: wodehouse
  10. Organization: Bellcore
  11. References: <1992Jul23.123609.11699@bony1.bony.com> <5618@vexpert.dbai.tuwien.ac.at>
  12.     <GEOFF.92Jul27100601@wodehouse.flash.bellcore.com>
  13.     <graham.712278529@galois>
  14. Date: 28 Jul 92 10:00:15
  15. Lines: 34
  16.  
  17. In article <graham.712278529@galois> graham@maths.su.oz.au (Graham Matthews) writes:
  18.    (Geoffrey Clemm) writes:
  19.    >I believe you missed the central point of Richie's article, namely that
  20.    >Eiffel 3.0 has a clean way of handling this situation, to quote:
  21.    >In article <1992Jul23.123609.11699@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:
  22.    >> Given this, the above call to "union" would be written like this
  23.    >> (using Eiffel 3 syntax):
  24.    >>     !!c.union (a,b);
  25.    >> Which I think is better. 
  26.    >With which I completely agree.  This avoids the unpleasant assymetry
  27.    >of c:=a.union(b).
  28.  
  29.    Personally I think this is just awful. I want to write
  30.  
  31.        c := a + b;        OR
  32.        c := a union b;
  33.  
  34.    Any other notation is completely non-suggestive.
  35.  
  36. Yes, generic functions are great, and languages like CLOS let you do
  37. just this.  Unfortunately, the uncontrolled nature of inheritance for
  38. generic functions can rapidly lead to a maintenance (and control flow)
  39. nightmare, something which is of great concern to Eiffel users.
  40.  
  41. The alternative, namely, an artificial assymetry around the first argument,
  42. is somewhat mitigated in Eiffel through the availability of creation
  43. instructions, (and would have been even more mitigated with the
  44. availability of creation expressions, as I have argued elsewhere :-).
  45.  
  46. Cheers,
  47.  
  48. Geoff
  49. --
  50. geoff@bellcore.com
  51.