home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / pascal / 6757 < prev    next >
Encoding:
Text File  |  1992-11-20  |  2.4 KB  |  54 lines
  1. Newsgroups: comp.lang.pascal
  2. Path: sparky!uunet!paladin.american.edu!news.univie.ac.at!hp4at!mcsun!news.funet.fi!network.jyu.fi!sakkinen
  3. From: sakkinen@jyu.fi (Markku Sakkinen)
  4. Subject: Re: Interesting design/implementation dilemma
  5. Message-ID: <1992Nov20.110009.19627@jyu.fi>
  6. Organization: University of Jyvaskyla, Finland
  7. References: <722091628.F00001@contrast.wlink.nl>
  8. Date: Fri, 20 Nov 1992 11:00:09 GMT
  9. Lines: 43
  10.  
  11. In article <722091628.F00001@contrast.wlink.nl> berend@contrast.wlink.nl (Berend de Boer) writes:
  12. >Lately when designing two objects, a printer object and a (print)job
  13. >object, an interesting design dilemma happened. I could choose:
  14. >1) let the printer object accept jobs, or
  15. >2) let the job print itself on a printer
  16. >
  17. >In Turbo Pascal:
  18. >1) Printer^.PrintJob(Job); or
  19. >2) Job^.Print(Printer);
  20.  
  21. What about conventional procedural style:
  22. 3) Print (printer, job);  ?
  23. As a comparison:
  24. in most purely object-oriented languages, any operation _must_ belong to
  25. one class.  This is rather inconvenient in cases like this where
  26. two or more objects have rather equal roles in the operation.
  27. If you need multiple polymorphism, the problem becomes severe.
  28.  
  29. >It happened that I could not choose between these two designs. Turbo
  30. >Pascal forced me to take the second. Here's how: I wanted the two
  31. >objects in two seperate units. The printer unit could not be overlaid,
  32. >but the Job unit could. The Job unit needed to use the printer unit
  33. >(else how could it print) If I wrote the units this way, the first
  34. >option gave me an circular reference error.  [...]
  35.  
  36. IMHO, a language that does not allow cycles in the "uses" relation
  37. between modules is brain-damaged.  A person I know was recently highly
  38. interested in Oberon;  one of the main reasons to drop it was that
  39. Oberon likewise disallows cycles.
  40. (The Extended Pascal standard, which supports modules, seems to allow
  41. cyclic export-import realationships.)
  42. In this special case, one way to eschew the restriction is to apply
  43. alternative 3 above in a third unit that imports both Printer and Job.
  44.  
  45. ----------------------------------------------------------------------
  46. Markku Sakkinen (sakkinen@jytko.jyu.fi)
  47.        SAKKINEN@FINJYU.bitnet (alternative network address)
  48. Department of Computer Science and Information Systems
  49. University of Jyvaskyla (a's with umlauts)
  50. PL 35
  51. SF-40351 Jyvaskyla (umlauts again)
  52. Finland
  53. ----------------------------------------------------------------------
  54.