home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3286 < prev    next >
Encoding:
Text File  |  1992-08-20  |  2.3 KB  |  46 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!sdd.hp.com!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
  3. From: johnson@m.cs.uiuc.edu (Ralph Johnson)
  4. Subject: Re: O.M() versus M(O) notation
  5. Message-ID: <1992Aug21.025530.19949@m.cs.uiuc.edu>
  6. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  7. References: <1992Aug5.162329.22871@ucunix.san.uc.edu>     <PCG.92Aug12205741@aberdb.aber.ac.uk>     <__5mtrq.objsys@netcom.com> <PCG.92Aug14170701@aberdb.aber.ac.uk>     <1992Aug15.124149.28538@m.cs.uiuc.edu>     <PCG.92Aug16184526@aberdb.aber.ac.uk>     <1992Aug16.212818.29943@m.c <PCG.92Aug21014009@aberdb.aber.ac.uk>
  8. Date: Fri, 21 Aug 1992 02:55:30 GMT
  9. Lines: 35
  10.  
  11. pcg@aber.ac.uk (Piercarlo Grandi) writes:
  12.  
  13. >So, here you seem to be saying that abstract classes in most OO
  14. >languages are a considerable mess, because they *ought* to be used as a
  15. >poor man's template facility, and then end up being used as a poor man's
  16. >interface definition facility too.
  17.  
  18. No, that is not what I am saying.  They are a good template facility.
  19. They are all the template facility that Smalltalk needs.  C++ needs
  20. "templates" in addition to abstract classes, so they are perhaps not
  21. as good for languages with static type checking.  They are not a good
  22. interface definition facility, it is true.  Or, even if it isn't true,
  23. I believe it!
  24.  
  25. >Which is exactly about my point, incidentally. Why not separate
  26. >interface defining, generic defining, and class assembling into three
  27. >separate facilities? Then your 'abstract classes' would have no reason
  28. >to exist, and inheritance as well.
  29.  
  30. Lots of people, including me, have argued for a long time that interface
  31. defining and class assembling should be separate facilities.  I call the
  32. relationship between interfaces subtyping, and the relationship between
  33. classes subclassing.  You are not going to get rid of inheritance, you
  34. are just going to call it by a different name.  Moreover, you are not
  35. going to get rid of abstract classes, either.  Abstract classes are an
  36. important design technique.  Abstract classes are more powerful than
  37. templates because you can do more than just fill in the missing 
  38. operations, you can also redefine the operations that are provided.
  39. Thus, the provided operations all become defaults that a new subclass
  40. can replace with a more efficient version.
  41.  
  42. Ralph Johnson -- University of Illinois at Urbana-Champaign
  43.  
  44.  
  45.  
  46.