home *** CD-ROM | disk | FTP | other *** search
/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / zip / language / xlisp_21.zoo / xlisp.txt < prev    next >
Text File  |  1990-02-28  |  15KB  |  449 lines
  1. From sce!mitel!uunet!snorkelwacker!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcso!hpfcbig!tim Fri Feb 16 07:18:45 EST 1990
  2. Article: 74 of comp.lang.lisp.x
  3. Path: cognos!sce!mitel!uunet!snorkelwacker!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcso!hpfcbig!tim
  4. From: tim@hpfcbig.SDE.HP.COM (Tim Mikkelsen)
  5. Newsgroups: comp.lang.lisp.x
  6. Subject: Re: intro to XLISP objects
  7. Message-ID: <1170005@hpfcbig.SDE.HP.COM>
  8. Date: 12 Feb 90 16:23:48 GMT
  9. References: <1170004@hpfcbig.SDE.HP.COM>
  10. Organization: HP SESD, Fort Collins, CO
  11. Lines: 434
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.                XLISP 2.0 OBJECTS PRIMER
  25.  
  26.  
  27.                      by 
  28.  
  29.                    Tim I Mikkelsen
  30.  
  31.  
  32.                   February 3, 1990
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.     Copyright  (c) 1990 by Tim I.  Mikkelsen.  All Rights  Reserved.
  42.     No part of this document may be copied, reproduced or translated
  43.     for commercial use without prior written  consent of the author.
  44.     Permission  is granted  for  non-commercial  use as long as this
  45.     notice is left intact.
  46.  
  47.  
  48.     ________________________________________________________________
  49.  
  50.     
  51.     One of the  features  in the design of XLISP is  object-oriented
  52.     programming.  This  primer is  intended to serve as a very brief
  53.     introduction  to the object  facilities of the XLISP 2.0 dialect
  54.     of LISP.  Note that the object  features  of XLISP are not based
  55.     on other existing object definitions in other LISP dialects.  If
  56.     you find problems in the primer, I'd appreciate hearing.
  57.  
  58.  
  59.             Tim Mikkelsen
  60.             4316 Picadilly Drive
  61.             Fort Collins, Colorado  80526
  62.  
  63.  
  64.  
  65. PROGRAMMING STYLES
  66. ______________________________________________________________________________
  67.  
  68.  
  69. There are many  programming  paradigms  (models).  Some of the paradigms
  70. are procedural, functional, rule-based, declarative and object-oriented.
  71. A language can have aspects of one or many of these programming  models.
  72.  
  73.  
  74. Procedure-Oriented
  75.  
  76. The programming paradigm most people are familiar with is the procedural
  77. style.  The primitives in procedural  programming  are:  subroutines and
  78. data  structures.  Through  these  primitives,   programmers  have  some
  79. limited abilities to share programs and program fragments.  C and Pascal
  80. are examples of procedural  languages.  Some procedural  languages (such
  81. as Modula and ADA) have  extensions  that provide for better  sharing of
  82. code.
  83.  
  84.  
  85. Object-Oriented Programming
  86.  
  87. Object-oriented  programming  is based  on the  primitives  of  objects,
  88. classes and messages.  Objects are defined in terms of classes.  Actions
  89. occur by sending a message to an object.  An object's  definition can be
  90. inherited  from  more  general  classes.  Objective-C  and C++ both  are
  91. object-oriented  dialects of the C language.  Many dialects of LISP have
  92. some object oriented extension (Flavors, Common LOOPS, CLOS and others).
  93. There  currently is standards  work  proceeding  to add  object-oriented
  94. programming to Common LISP.
  95.  
  96.  
  97. Object Oriented Programming
  98.  
  99. So, the  object-oriented  programming model is based around the concepts
  100. of objects,  classes and messages.  An object is essentially a black box
  101. that contains internal state  information.  You send an object a message
  102. which causes the object to perform some  operation.  Objects are defined
  103. and described through classes.
  104.  
  105. One aspect of an object is that you do not have to know what is inside -
  106. or how it  works - to be able to use it.  From a  programming  point  of
  107. view,  this is very  handy.  You can  develop a series  of  objects  for
  108. someone to use.  If you need to change what goes on inside, the users of
  109. the objects should be unaware.
  110.  
  111. Another aspect of objects is that of  inheritance.  You can build up new
  112. classes  from  existing  classes  by  inheriting  the  existing  class's
  113. functionality  and then extending the new  definition.  For example, you
  114. can  define a tool class  (with  various  attributes)  and then go about
  115. creating  object  instances  tool-1,  tool-2,  and so on.  You can  also
  116. create new sub-classes of the tool class like  power-tool.  This is also
  117. very handy because you don't have to  re-implement  something if you can
  118. build it up from existing code.
  119.  
  120.  
  121.  
  122.  
  123. XLISP OBJECT-ORIENTED PROGRAMMING
  124. ______________________________________________________________________________
  125.  
  126.  
  127.  
  128. XLISP OBJECT TERMINOLOGY
  129.  
  130. There  are, as  previously  mentioned,  many  different  languages  with
  131. object-oriented  extensions and facilities.  The terminology, operations
  132. and  styles of these are very  different.  Some of the main  definitions
  133. for XLISP's object-oriented extensions are:
  134.  
  135.     Object data type        The OBJECT DATA TYPE is a built-in  data
  136.                 type of  XLISP.  Members  of the  object
  137.                 data  type  are  object   instances  and
  138.                 classes.
  139.  
  140.     Object instances        An  OBJECT   INSTANCE  is  a   composite
  141.                 structure that contains  internal  state
  142.                 information,  methods  (the  code  which
  143.                 respond to  messages),  a pointer to the
  144.                 object  instance's  defining class and a
  145.                 pointer  to  the  object's  super-class.
  146.                 XLISP   contains   no  built-in   object
  147.                 instances.
  148.  
  149.     Class objects           A  CLASS  OBJECT  is,  essentially,  the
  150.                 template for defining the derived object
  151.                 instances.  A  class  object,   although
  152.                 used  differently  from a simple  object
  153.                 instance,  is  structurally  a member of
  154.                 the  object   data   type.  It  is  also
  155.                 contains  the  linking   mechanism  that
  156.                 allows  you to build  class  hierarchies
  157.                 (sub-classes and  super-classes).  XLISP
  158.                 contains  two  built-in  class  objects:
  159.                 OBJECT and CLASS.
  160.  
  161.     Message selector        The MESSAGE  SELECTOR is the symbol that
  162.                 is used to  select a  particular  action
  163.                 (Method) from the object.
  164.  
  165.     Message                 The  MESSAGE is the  combination  of the
  166.                 message  selector  and the data (if any)
  167.                 to be sent to the object.
  168.  
  169.     Method                  The METHOD is the actual  code that gets
  170.                 executed  when the object  receives  the
  171.                 Message.
  172.  
  173.  
  174.  
  175. SENDING MESSAGES
  176.  
  177. The  mechanism  for  sending  messages to XLISP  objects is via the SEND
  178. function.  It takes an object, a message  selector and various  optional
  179. arguments (depending on the message selector).
  180.  
  181. The way that a user  creates a new object is to send a :NEW message to a
  182. previously  defined  class.  The  result  of this  SEND will  return  an
  183. object, so this is normally preceded by a SETQ.  The values shown in the
  184. examples  that follow may not match what you see if you try this on your
  185. version of XLISP - this is not an error.  The  screens  that are used in
  186. the various examples are similar to what you should see on your computer
  187. screen.  The ">" is the normal XLISP prompt (the  characters that follow
  188. the prompt is what you should type in to try these examples).
  189.  
  190.  
  191.      ________________________________________________________________
  192.     |
  193.     |    > (setq my-object (send object :new))
  194.     |    #<Object: #2e100>
  195.     |________________________________________________________________
  196.  
  197.  
  198. The object  created here is of limited  value.  Most often, you create a
  199. class  object and then you create  instances  of that  class.  So in the
  200. following  example, a class called MY-CLASS is created that inherits its
  201. definition from the a built-in CLASS definition.  Then two instances are
  202. created of the new class.
  203.  
  204.      ________________________________________________________________
  205.     |
  206.     |    > (setq my-class (send class :new '()))
  207.     |    #<Object: #27756>
  208.     |    
  209.     |    > (setq my-instance (send my-class :new))
  210.     |    #<Object: #27652>
  211.     |
  212.     |    > (setq another-instance (send my-class :new))
  213.     |#<Object: #275da>
  214.     |________________________________________________________________
  215.  
  216.  
  217.  
  218. CLASSES
  219.  
  220. Previously,  a :NEW  message was used to create an object.  The  message
  221. used to see what is in an object is the :SHOW message.
  222.  
  223.      ________________________________________________________________
  224.     |
  225.     |    > (send my-class :show)
  226.     |    Object is #<Object: #27756>, Class is #<Object: #23fe2>
  227.     |      MESSAGES = NIL
  228.     |      IVARS = NIL
  229.     |      CVARS = NIL
  230.     |      CVALS = NIL
  231.     |      SUPERCLASS = #<Object: #23fd8>
  232.     |      IVARCNT = 0
  233.     |      IVARTOTAL = 0
  234.     |    #<Object: #27756>
  235.     |________________________________________________________________
  236.  
  237.  
  238. From the display of the MY-CLASS  object you can see there are a variety
  239. of components.  The components of a class are:
  240.  
  241.     Class Pointer           This  pointer  shows to what  class  the
  242.                 object (instance or class) belongs.  For
  243.                 a  class,  this  always  points  to  the
  244.                 built-in  object  CLASS.  This  is  also
  245.                 true  of the  CLASS  object,  its  class
  246.                 pointer points to itself.
  247.  
  248.     Superclass Pointer      This  pointer  shows what the next class
  249.                 up the class  hierarchy is.  If the user
  250.                 does  not  specify  what  class  is  the
  251.                 superclass,   it  will   point   to  the
  252.                 built-in class OBJECT.
  253.  
  254.     Messages                This  component  shows what messages are
  255.                 allowed   for   the   class,   and   the
  256.                 description  of the method  that will be
  257.                 used.  If the method is  system-defined,
  258.                 it will show up in the form of '#<Subr-:
  259.                 #18b98>'.  Remember   that   the   class
  260.                 hierarchy    (through   the   Superclass
  261.                 Pointer) is  searched  if the  requested
  262.                 message is not found in the class.
  263.  
  264.     Instance Variables      This   component   lists  what  instance
  265.                 variables will be created when an object
  266.                 instance is created.  If no instances of
  267.                 the class  exist,  there are no Instance
  268.                 Variables.  If there are 5 instances  of
  269.                 a  class,  there  are  5  complete   and
  270.                 different   groups   of   the   Instance
  271.                 Variables.
  272.  
  273.     Class Variables         The  CLASS  VARIABLES  (CVAR)  component
  274.     and Values        lists what class variables  exist within
  275.                 the  class.  The  Class  Values   (CVAL)
  276.                 component  shows what the current values
  277.                 of the variables  are.  Class  Variables
  278.                 are used to hold state information about
  279.                 a class.  There  will be |Bone of each|A
  280.                 of the Class  Variables,  independent of
  281.                 the  number of  instances  of the  class
  282.                 created.
  283.  
  284. A BETTER EXAMPLE
  285.  
  286. The  example  previously  shown  does work, but the class and  instances
  287. created  don't really do anything of  interest.  The  following  example
  288. sets up a tool class and creates some tool instances.
  289.  
  290.      ________________________________________________________________
  291.     |
  292.     |    > (setq my-tools (send class :new '(power moveable operation)))
  293.     |    #<Object: #277a6>
  294.     |
  295.     |    > (send my-tools :answer :isnew '(pow mov op) 
  296.     |                     '((setq power pow)
  297.     |                       (setq moveable mov)
  298.     |                       (setq operation op)))
  299.     |    #<Object: #277a6>
  300.     |
  301.     |    > (setq drill (send my-tools :new 'AC t 'holes))
  302.     |    #<Object: #2ddbc>
  303.     |
  304.     |    > (setq hand-saw (send my-tools :new 'none t 'cuts))
  305.     |    #<Object: #2dc40>
  306.     |
  307.     |    > (setq table-saw (send my-tools :new 'AC nil 'cuts))
  308.     |    #<Object: #2db00>
  309.     |________________________________________________________________
  310.  
  311.  
  312. So, a class of objects called MY-TOOLS was created.  Note that the class
  313. object  MY-TOOLS was created by sending the :NEW message to the built-in
  314. CLASS  object.  Within  the  MY-TOOL  class,  there are three  instances
  315. called DRILL, HAND-SAW and TABLE-SAW.  These were created by sending the
  316. :NEW message to the MY-TOOLS  class object.  Notice that the  parameters
  317. followed the message selector.
  318.  
  319.  
  320. INSTANCES
  321.  
  322. The  following  is a display of the  contents of some of the  previously
  323. created instances:
  324.  
  325.      ________________________________________________________________
  326.     |
  327.     |    > (send drill :show)
  328.     |    Object is #<Object: #2ddbc>, Class is #<Object: #277a6>
  329.     |      POWER = AC
  330.     |      MOVEABLE = T
  331.     |      OPERATION = HOLES
  332.     |    #<Object: #2ddbc>
  333.     |
  334.     |    > (send hand-saw :show)
  335.     |    Object is #<Object: #2dc40>, Class is #<Object: #277a6>
  336.     |      POWER = NONE
  337.     |      MOVEABLE = T
  338.     |      OPERATION = CUTS
  339.     |    #<Object: #2dc40>
  340.     |________________________________________________________________
  341.  
  342.  
  343. From  the  display  of  these  instances  you  can see  there  are  some
  344. components and values.  The components of an instance are:
  345.  
  346.     Class Pointer           This  pointer  shows to which  class the
  347.                 current object instance  belongs.  It is
  348.                 through this link that the system  finds
  349.                 the methods to execute for the  received
  350.                 messages.
  351.  
  352.     Instance Variables      The Instance  Variables (IVAR) component
  353.     and Values        lists what  variables  exist  within the
  354.                 instance.  The Instance Values component
  355.                 holds  what the  current  values  of the
  356.                 variables  are.  Instance  Variables are
  357.                 used to hold state  information for each
  358.                 instance.  There  will  be  a  group  of
  359.                 Instance Variables for each instance.
  360.  
  361.  
  362.  
  363.  
  364. METHODS
  365.  
  366. There have been a few of the messages and methods in XLISP shown to this
  367. point (:NEW and :SHOW).  The following are the methods built into XLISP:
  368.  
  369.     :ANSWER         The  :ANSWER  method  allows  you to  define  or
  370.             change methods within a class.
  371.  
  372.     :CLASS         The :CLASS method returns the class of an object.
  373.  
  374.     :ISNEW          The :ISNEW method  causes an instance to run its
  375.             initialization  code.  When the :ISNEW method is
  376.             run on a class, it resets the class state.  This
  377.             allows  you  to  re-define  instance  variables,
  378.             class variables, etc.
  379.  
  380.     :NEW            The :NEW method allows you to create an instance
  381.             when the :NEW message is sent to a  user-defined
  382.             class.  The :NEW  method  allows you to create a
  383.             new class (when the :NEW  message is sent to the
  384.             built-in CLASS).
  385.  
  386.     :SHOW         The :SHOW method displays the instance or class.
  387.  
  388.  
  389.  
  390. SENDING MESSAGES TO A SUPERCLASS
  391.  
  392. In  addition  to the SEND  function,  there is another  function  called
  393. SEND-SUPER.  The SEND-SUPER  function causes the specified message to be
  394. performed  by the  superclass  method.  This  is a  mechanism  to  allow
  395. chaining of methods in a class hierarchy.  This chaining behavior can be
  396. achieved  by  creating a method  for a class with the  :ANSWER  message.
  397. Within the body of the  method,  you  include a  SEND-SUPER  form.  This
  398. function is allowed only inside the  execution of a method of an object.
  399.  
  400.  
  401. OBJECT AND CLASS
  402.  
  403. The definition of the built-in class OBJECT is:
  404.  
  405.      ________________________________________________________________
  406.     |
  407.     |    > (send object :show)
  408.     |    Object is #<Object: #23fd8>, Class is #<Object: #23fe2>
  409.     |      MESSAGES = ((:SHOW . #<Subr-: #23db2>) 
  410.     |                (:CLASS . #<Subr-: #23dee>) 
  411.     |              (:ISNEW . #<Subr-: #23e2a>))
  412.     |      IVARS = NIL
  413.     |      CVARS = NIL
  414.     |      CVALS = NIL
  415.     |      SUPERCLASS = NIL
  416.     |      IVARCNT = 0
  417.     |      IVARTOTAL = 0
  418.     |    #<Object: #23fd8>
  419.     |________________________________________________________________
  420.  
  421.  
  422. Note that OBJECT is a class - as opposed to an "instance-style"  object.
  423. OBJECT has no superclass, it is the top or root of the class  hierarchy.
  424. OBJECT's class is CLASS.
  425.  
  426.      ________________________________________________________________
  427.     |
  428.     |    > (send class :show)
  429.     |    Object is #<Object: #23fe2>, Class is #<Object: #23fe2>
  430.     |      MESSAGES = ((:ANSWER . #<Subr-: #23e48>) 
  431.     |                (:ISNEW . #<Subr-: #23e84>) 
  432.     |              (:NEW . #<Subr-: #23ea2>))
  433.     |      IVARS = (MESSAGES IVARS CVARS CVALS SUPERCLASS 
  434.     |           IVARCNT IVARTOTAL)
  435.     |      CVARS = NIL
  436.     |      CVALS = NIL
  437.     |      SUPERCLASS = #<Object: #23fd8>
  438.     |      IVARCNT = 7
  439.     |      IVARTOTAL = 7
  440.     |    #<Object: #23fe2>
  441.     |________________________________________________________________
  442.  
  443.  
  444. CLASS has a superclass of OBJECT.  It's class is itself - CLASS. 
  445.  
  446.  
  447.  
  448.  
  449.