home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3282 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  2.4 KB

  1. Xref: sparky comp.object:3282 comp.lang.clos:685
  2. Path: sparky!uunet!mcsun!uknet!gdt!aber!aberfa!pcg
  3. From: pcg@aber.ac.uk (Piercarlo Grandi)
  4. Newsgroups: comp.object,comp.lang.clos
  5. Subject: Re: Beginner's Question - CLOS
  6. Message-ID: <PCG.92Aug21005641@aberdb.aber.ac.uk>
  7. Date: 21 Aug 92 00:56:41 GMT
  8. References: <16u2tpINN9ad@early-bird.think.com>
  9.     <1992Aug19.213818.21709@tfs.com>
  10.     <DCMARTIN.92Aug19151550@fascet.msi.com>
  11.     <170fu1INNmfh@early-bird.think.com>
  12. Sender: news@aber.ac.uk (USENET news service)
  13. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  14. Organization: Prifysgol Cymru, Aberystwyth
  15. Lines: 39
  16. In-Reply-To: barmar@think.com's message of 20 Aug 92 16: 06:25 GMT
  17. Nntp-Posting-Host: aberdb
  18.  
  19. On 20 Aug 92 16:06:25 GMT, barmar@think.com (Barry Margolin) said:
  20. NNTP-Posting-Host: telecaster.think.com
  21.  
  22. barmar> dcmartin@msi.com writes:
  23.  
  24. dcmartin> (Eric Smith) writes:
  25.  
  26. Smith> But doesn't that make method dispatch very time consuming?  It
  27. Smith> seems like it would involve searching for the method in tables,
  28. Smith> and that the amount of time consumed would depend on how many
  29. Smith> methods were in those tables and how many class arguments each
  30. Smith> method had.
  31.  
  32. dcmartin> Yes, if you did things that way.  In fact, you can determine
  33. dcmartin> at compile time what the argument types are and then put in
  34. dcmartin> the appropriate call to the appropriate function.
  35.  
  36. barmar> That's not true in general, unless you use some
  37. barmar> implementation-dependent mechanism to tell the compiler that the
  38. barmar> class named in a specializer or type declaration will never have
  39. barmar> any subclasses, or that these subclasses won't override the
  40. barmar> method.
  41.  
  42. Fully agreed, but this information can be easily deduced by a 'system
  43. builder', i.e. an intelligent linker, like Eiffel has (for more or less
  44. this reason). A system builder can create a complete list of all the
  45. types in an application (unless they can be defined at run time), and
  46. can do such overload resolution at system building time, statically. I
  47. think a 'system building' tool is something that is quite useful in
  48. general, especially if it can be used more or less incrementally.
  49.  
  50. barmar> If you don't do this, then an object of a subclass may be
  51. barmar> provided, and [ ... ]
  52.  
  53. ... overloading cannot be assumed to be statically bounded.
  54. --
  55. Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
  56. Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
  57. Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
  58.