home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / object / 3399 < prev    next >
Encoding:
Text File  |  1992-09-02  |  3.1 KB  |  55 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!usc!sdd.hp.com!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
  3. From: johnson@m.cs.uiuc.edu (Ralph Johnson)
  4. Subject: Re: Object-Oriented Methodologies - Class Specifications
  5. Message-ID: <1992Sep3.033015.31493@m.cs.uiuc.edu>
  6. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  7. References: <1992Sep1.220559.10346@m.cs.uiuc.edu> <715276480.1.p00058@mail.psi.net> <1992Sep2.135247.11696@bcrka451.bnr.ca>
  8. Date: Thu, 3 Sep 1992 03:30:15 GMT
  9. Lines: 44
  10.  
  11. In response to an article of mine, sjm@bcrki65.bnr.ca (Stuart MacMartin) writes: 
  12.  
  13. >Yes, I suppose.  But intersectLine???  Do you really support having a
  14. >pair-wise solution?  If I want to add another GeometricObject if there are,
  15. >say, 10 already, do I add 10 intersection methods????  What about the 
  16. >symmetric intersection methods in the other classes?  How do I then find
  17. >the intersection of two arbitrary geometric objects?  Must I be able to
  18. >find the types at runtime?
  19.  
  20. Let's forget about OOP, and just think about geometry.  An algorithm to
  21. test whether two circles intersect is different from one that tests whether
  22. a cicle intersects with a line, or whether two rectangles intersect.
  23. We can have default approximate algorithms, like check whether the bounding
  24. boxes of the two geometric objects intersect.  We can also have slower
  25. algorithms for arbitrary polygons that can be replaced by more efficient
  26. algorithms for special cases like rectangles.  The *problem domain* implies
  27. that a solution will have to have lots of special cases.
  28.  
  29. Several people have mentioned that CLOS generic functions are the correct
  30. solution to this problem, and they are right.  Those of us who use
  31. languages without generic functions use double-dispatching to solve the
  32. problem, which is essentially the same as generic functions if you squint
  33. right.  (Since I program in Smalltalk and C++, I have a perpetual squint.)
  34. This has the obvious problems that adding new classes requires modifying
  35. existing ones, but that is because we are dealing with a problem whose
  36. solution depends on the classes of more than one object.  If you don't
  37. like that then you can always go back to CASE statements.  The real solution
  38. is to provide better language and programming environment support for
  39. operations that depend on the class of several objects, whether this
  40. be generic functions or something else.
  41.  
  42. >I don't want my compiling or (especially!) my module size to be 
  43. >adversely affected.  I have seen cases where using one routine from a 
  44. >utility package increased the size of the executable by 50% because of all 
  45. >the extraneous junk that was pulled in due to this packaging philosophy.  
  46. >Will this happen in your case, or am I unduly worried about a problem that
  47. >doesn't appear in standard OO languages?
  48.  
  49. This will happen in all the C++ systems I know about.  Smalltalk systems
  50. leave the decision for what gets included up to you (by letting you specify
  51. what gets stripped), which is no better.  Language implementers need to
  52. take this problem seriously, or it will inhibit the use of reusable software.
  53.  
  54. Ralph Johnson -- University of Illinois at Urbana-Champaign
  55.