home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3243 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  3.9 KB
  1. Path: sparky!uunet!mcsun!uknet!gdt!aber!aberfa!pcg
  2. From: pcg@aber.ac.uk (Piercarlo Grandi)
  3. Newsgroups: comp.object
  4. Subject: Re: O.M() versus M(O) notation
  5. Message-ID: <PCG.92Aug18135725@aberdb.aber.ac.uk>
  6. Date: 18 Aug 92 13:57:25 GMT
  7. References: <1992Aug5.162329.22871@ucunix.san.uc.edu> <PCG.92Aug12205741@aberdb.aber.ac.uk>
  8.     <__5mtrq.objsys@netcom.com> <PCG.92Aug14170701@aberdb.aber.ac.uk>
  9.     <1992Aug15.124149.28538@m.cs.uiuc.edu>
  10.     <PCG.92Aug16184526@aberdb.aber.ac.uk> <1992Aug16.212818.29943@m.cs.
  11. Sender: news@aber.ac.uk (USENET news service)
  12. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  13. Organization: Prifysgol Cymru, Aberystwyth
  14. Lines: 77
  15. In-Reply-To: graham@maths.su.oz.au's message of 17 Aug 92 11: 44:34 GMT
  16. Nntp-Posting-Host: aberdb
  17.  
  18. On 17 Aug 92 11:44:34 GMT, graham@maths.su.oz.au (Graham Matthews) said:
  19.  
  20. graham> Could someone provide a concrete example of where seperating
  21. graham> interface and implementation buys one a whole lot,
  22.  
  23. It's not really about 'buying you a whole lot'; it's that it's
  24. *necessary*, and either it has to be done "properly", or by perverting
  25. language facilities to other ends designed.
  26.  
  27. graham> or where you want to inherit part of an interface.
  28.                  ^^^^^^^
  29. The seven letter word! :-) Don't use that, it's misleading.
  30.  
  31. graham> I am not saying that it can't be done or isn't useful, I am
  32. graham> merely interested in an illustrative example.
  33.  
  34. Well, my favourite example has already been given: deque, stack and
  35. queue.
  36.  
  37. One can design a general set of components with which one can build a
  38. deque, and then derive queues and stacks from deque.
  39.  
  40. For example, one possible interface/protocol/signature/... of deque
  41. might be:
  42.  
  43.     top, bottom    (return the values at one of the two ends)
  44.     push, pop    (operate on the top)
  45.     append, detach    (operate on the bottom)
  46.  
  47. then that of stack might be:
  48.  
  49.     deque EXCEPT bottom,append,detach
  50.  
  51. The same for implementation and specification
  52.  
  53. Everybody will have noticed that the reverse might be done too; one
  54. builds stack and queue components and merges them to get a deque.
  55.  
  56. This is however bound to be less useful; it is only by "chance" that
  57. independently designed stack and queue components will fit nicely
  58. together. It usually pays to design the most general 'type' and then
  59. subset it, or enrich it with quite different properties. It then pays to
  60. have symbolic reduction engines as compilers (Turchin's REFAL
  61. supercompiler, many other previous/later ones), as these can efficiently
  62. specialize implementations.
  63.  
  64. But this looks all pie-in-the-sky! Most languages don't even have
  65. partial application to specialize functions, not to mention
  66. continuations.
  67.  
  68. Other simple examples that spring to mind are graph/tree, various
  69. varieties of indexing systems (various types of b-trees, of static
  70. indexes, of hashes), various multiple precision number systems, etc.
  71.  
  72. In general there are many cases where arbitrary algebras on interfaces,
  73. implementations and specifications are useful, and typically:
  74.  
  75. TOP DOWN
  76.   when there are several denoted type/type denotations that are
  77.   related; mathematicians have the habit, just like programmers, to
  78.   develop algebraic structures by deformation of existing ones.
  79.  
  80. BOTTOM UP
  81.   when there are complex systems tend to develop over time like
  82.   algebraic structures, by deformation of existing ones; requirements
  83.   change a bit, implementations get extended or rewritten piecemeal, ...
  84.  
  85. In neither case the deformation is likely to be hierarchical, as some
  86. participant in this discussion would have us believe; the keyword, let
  87. me say, is 'extended subset'. Mix and match, in all the three dimensions
  88. of interface, specification, implementation, seems to be the rule rather
  89. than exception. But maybe, as somebody has remarked, I am not doing
  90. *REAL* OO systems.
  91. --
  92. Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
  93. Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
  94. Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
  95.