home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / object / 5023 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  6.1 KB
  1. Path: sparky!uunet!pipex!warwick!uknet!gdt!aber!fronta.aber.ac.uk!pcg
  2. From: pcg@aber.ac.uk (Piercarlo Grandi)
  3. Newsgroups: comp.object
  4. Subject: Classes are procedures, objects are closures in class based OO languages
  5. Summary: class based OO languages demistifyed; important revelations on
  6.     the role of seductive Nordic languages; relentless advertising
  7.     for two books; what about me getting a life instead of writing
  8.     such primer level obvieties;
  9. Message-ID: <PCG.93Jan22170223@decb.aber.ac.uk>
  10. Date: 22 Jan 93 17:02:23 GMT
  11. References: <1993Jan13.061114.18430@netcom.com>
  12.     <PCG.93Jan14154212@decb.aber.ac.uk>
  13.     <1993Jan15.033713.27130@netcom.com>
  14.     <PCG.93Jan19235921@decb.aber.ac.uk>
  15. Sender: news@aber.ac.uk (USENET news service)
  16. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  17. Organization: Prifysgol Cymru, Aberystwyth
  18. Lines: 137
  19. In-Reply-To: pcg@aber.ac.uk's message of Tue, 19 Jan 1993 23: 59:21 GMT
  20. Nntp-Posting-Host: decb.aber.ac.uk
  21.  
  22.  
  23. on [Tue, 19 Jan 1993 23:59:21 GMT] I had written a little article to
  24. show how (class based) OO was born out of making it possible to have
  25. multiple persistent instances of procedure contexts (closures), to
  26. explain my short description:
  27.  
  28. pcg> More precisely objects are values of a procedure instance
  29. pcg> (closure/continuation) record type.
  30.  
  31. Rereading my article (I often find rereading my articles interesting as
  32. I can learn new things from them :-> ;->) I have realized that the
  33. example could have structured better, in particular in two steps, to
  34. make more easily discernible the (Norse) legerdemain that is being
  35. applied.
  36.  
  37. I hope the readership of this distinguished newsgroup will not be unduly
  38. distressed by a further exposition of one of my pet subjects :->.
  39.  
  40. So, here it is again. Let's imagine we have the following Pascal
  41. program fragment:
  42.  
  43.       PROCEDURE complex(re, im : real);
  44.  
  45.         TYPE complex_value = RECORD re,im: real; END;
  46.  
  47.         VAR self : complex_value;
  48.  
  49.         FUNCTION plus(other : complex_value) : complex_value;
  50.           VAR sum : complex_value;
  51.         BEGIN
  52.           sum.re := self.re + other.im;
  53.           sum.im := self.im + other.im;
  54.         END;
  55.  
  56.       BEGIN
  57.         self.re := re;
  58.         self.im := im;
  59.       END;
  60.  
  61. This does not look very helpful. We can only deal with the values that
  62. have been declared inside 'complex', and we can only operate on them in
  63. the body of procedure complex. The fundamental reasons are that there
  64. can be only one instance of a procedure at any one time (but for
  65. recursion) and since this one instance cannot outlive it caller, its
  66. local variables can only be accessed inside it.
  67.  
  68. But we can stipulate that like in Simula 67:
  69.  
  70. * Procedures may have multiple instances.
  71.  
  72. * A procedure instance context (its closure) may outlive the end of
  73.   the execution of its body code.
  74.  
  75. * A procedure name defines also a type/mode, that of its closure,
  76.   and one may declare pointers of such type/mode.
  77.  
  78. * A procedure instance is created by invoking it prefixed with 'NEW',
  79.   and this returns a pointer to the instance.
  80.  
  81. * It is possible to access the local attributes of a procedure
  82.   closure with dot notation.
  83.  
  84. Then we can write the following Pascal 67 program:
  85.  
  86.     PROGRAM oo_classes_are_procedures(output);
  87.  
  88.       PROCEDURE complex(init_re, init_im : real);
  89.  
  90.         VAR re,im : real;
  91.  
  92.         FUNCTION plus(other : ^complex) : ^complex;
  93.         BEGIN
  94.           RETURN NEW complex(re+other^.re,i+_other^.im);
  95.         END;
  96.  
  97.       BEGIN
  98.         re := init_re;
  99.         im := init_im;
  100.       END;
  101.  
  102.       VAR i,u,s : ^complex;
  103.  
  104.     BEGIN
  105.       i := NEW complex(0.0,1.0);
  106.       u := NEW complex(1.0,0.0);
  107.       s := i^.plus(u);
  108.       writeln('s is (',s^.re,',',s^.im,')');
  109.     END.
  110.  
  111. (note that this is identical to Simula 67 except for one extremely minor
  112. detail; note also that since Pascal does not allow for pointers to
  113. procedures, we can use '^ procedure_name' to mean 'pointer to procedure
  114. instance', else we would have to have a way of disinguishing between the
  115. type/mode of a procedure and that of one of its instances/closures).
  116.  
  117. To conclude, some observations:
  118.  
  119. * Like in Simula 67, we stipulated that one can only define *pointers*
  120.   to procedure instances. This is actually not necessary in general, and
  121.   some would argue that this is not desirable too (despite the not all
  122.   unfavourable expirience with pointer based OO and non OO languages
  123.   like Lisp, CLU, Simula 67, Smalltalk, and the first version of
  124.   Eiffel). The reasons for which one could only have pointers to
  125.   procedure instances (objects) in Simula 67 are incidental to the way
  126.   it was derived from Algol 60, not essential to OO.
  127.  
  128. * The above situation is exactly the same as in in all well known class
  129.   based OO languages, from Smalltalk to C++ to Eiffel, even if these
  130.   hide the fact behind a slightly different syntax. The identical
  131.   situation can reproduced in Scheme, in a slightly clearer way. This
  132.   time I chose Pascal instead of Scheme because Scheme is less familiar
  133.   to most people. I could not choose C because nested procedures are
  134.   essential to the effect, as only with nested (lexical) procedure
  135.   scopes we can generate the right sort of closure.
  136.  
  137. * Having objects be procedure instances and classes be procedures has
  138.   the unfortunate effect of being constrained by the nested scope
  139.   properties of procedures in conventional languages. This results in
  140.   difficulties with non hierarchical program structures: not by chance
  141.   the seminal paper on the OO decomposition paradigm by Dahl an Hoare
  142.   has title "Hierarchical Program Structures". After CLOS I think it it
  143.   is apparent (to me at least) that getting to OO via the more direct
  144.   overloading route is more flexible, as overloading can be made to
  145.   depend on multiple parameters, not just on that of the procedure
  146.   instance.
  147.  
  148. Finally, I hope that the readers of this newsgroup (those who haven't
  149. already read them) will run, not walk, to the nearest bookshop (not the
  150. library: you want your very own copy to read at leisure) to get a copy
  151. of "Structured Programming" and "Structure and Intepretation of Computer
  152. Programs" (no, I don't get a commission on the sale of these books).
  153.  
  154. Learned quote of the month: "[I can vaguely recall seeing closures
  155. equated to blocks, somewhere]". SICP, SICP, bless this soul! :-)
  156. --
  157. Piercarlo Grandi <pcg@aber.ac.uk> c/o Dept of CS
  158. University of Wales, Penglais, Aberystwyth SY23 3BZ, UK
  159.