home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / object / 3418 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  1.5 KB
  1. Path: sparky!uunet!olivea!hal.com!decwrl!csus.edu!netcom.com!objsys
  2. From: objsys@netcom.com (Bob Hathaway)
  3. Newsgroups: comp.object
  4. Subject: Re: Object-Oriented Methodologies - Class Specifications
  5. Message-ID: <#0ln+2c.objsys@netcom.com>
  6. Date: 4 Sep 92 01:31:34 GMT
  7. References: <715276480.1.p00058@mail.psi.net> <1992Sep2.135247.11696@bcrka451.bnr.ca> <1992Sep3.033015.31493@m.cs.uiuc.edu>
  8. Organization: Object Systems
  9. Lines: 22
  10.  
  11. In article <1992Sep3.033015.31493@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
  12. >>  ... [On object knowledge of geometry functions] ...
  13. >Several people have mentioned that CLOS generic functions are the correct
  14. >solution to this problem, and they are right.
  15.  
  16. Packaged functions work Ok but they seem identical to an OO manager approach.
  17. A geometry package with all of the geometry functions could be declared or
  18. a geometry object with all of the geometry functions as member functions could
  19. be declared.  No real geometry object has to exist with C++'s static functions
  20. and object and package qualification isn't much different.  Assuming dynamic
  21. selection is available for both, is there really any difference?  
  22.  
  23. bob
  24. objsys@netcom.com
  25.  
  26. P.S.  I still contend that dynamic functions are just functions and generic
  27. functions aren't necessary for selection since they could be eliminated
  28. from the language without a semantic difference.  The methods are all that
  29. are *necessary*, no?
  30.  
  31. P.S.S.  Thank you very much Barry Margolin for your type/class answer; I'm
  32.   considering it.
  33.