Xscheme object oriented? 
Author Message
 Xscheme object oriented?

David Michael Betz version of scheme (version 0.17/0.20) (The Amiga port) is
titled:  XSCHEME An Object-oriented Scheme; however, the only reference in
the manual to any syntax that even mentions objects is under the section
expressions (page 5):   (<object> <selector> <operand>...).  

How does one define a class, and an instance of a class, inheritance,
construction/destruction, etc...?

Is there any further documentation on the object oriented elements of
Xscheme.

Thanks,  Roger



Fri, 29 Jul 1994 04:49:26 GMT  
 Xscheme object oriented?


Quote:
> David Michael Betz version of scheme (version 0.17/0.20) (The Amiga port) is
> titled:  XSCHEME An Object-oriented Scheme; however, the only reference in
> the manual to any syntax that even mentions objects is under the section
> expressions (page 5):   (<object> <selector> <operand>...).  

> How does one define a class, and an instance of a class, inheritance,
> construction/destruction, etc...?

> Is there any further documentation on the object oriented elements of
> Xscheme.

Xscheme and Xlisp use very similar OOP systems. The xscheme documentation
contains scant information on how to use the OOP system, but there is a
good amount of documentation on Xlisp. Unless you're a dogmatic
scheme-head, you should be able to see through the CommonLisp-isms in the
XLISP docs and gain an understanding of the XLISP/XSCHEME OOP systems.

The XLISP documentation is part of the documentation for WINTERP (OSF/Motif
Widget INTERPreter) which is available via anon ftp from
export.lcs.mit.edu, directory contrib/winterp, file winterp-1.13.tar.Z;
WINTERP is also available on the MIT X11r5 contrib distribution (under
contrib/motif/clients/winterp).

In the distribution, you'll find:
        (1) An introduction to using XLISP OOP, and examples of using OOP with
            UI objects implemented as Motif widgets. (winterp/doc/winterp.doc)
        (2) Tim Mikkelsen's XLISP 2.0 object primer (winterp/doc/XlispOOP.doc)
        (3) Tim Mikkelsen's XLISP 2.0 Reference Manual (winterp/doc/XlispRef.doc)
        (4) winterp/examples/*.lsp for examples of using OOP in XLISP

I'm posting excepts from (1) and (2) below.

------------------------------------------------------------------------------
* Introduction to XLISP objects and Widgets.

WINTERP uses XLISP's object system as its interface to the class hierarchy
of widgets provided by Motif. Specifically, each Motif widget class is
represented by one or more object classes in WINTERP.  In order to best
understand the capabilities of WINTERP's Motif interface, a brief review of
the XLISP object system is in order. You may also want to consult the XLISP
documentation ./../doc/xlisp.doc and ./../doc/XlispRef.doc for a more
precise definition of the object system. Further examples may be found in
file ./../doc/XlispOOP.doc, Tim Mikkelsen's "XLISP 2.0 OBJECTS PRIMER."

XLISP Classes describe the type of a particular object by declaring a set
of variables held in each object. These "instance variables" may only be
accessed by "methods" that respond to "messages" sent to the object.
Methods are defined for particular classes, and functionality of other
classes may be incorporated into new classes via "inheritance". From XLISP,
Motif widget classes look just like normal XLISP objects -- that means that
you can easily extend the functionality of Motif widgets by adding your own
methods to a particular widget class. You may also use inheritance to
attach your own data structures to widgets. The result is that WINTERP
provides a very clean way to interactively rapid-prototype an application,
while also providing mechanisms for code structuring and reuse.  The latter
is necessary in evolving from prototype to a structured, maintainable, and
customizable deliverable.

** Creating new objects.

Create a new instance of a class by sending the message :NEW to
<a_class_instance>:

        (SEND <a_class_instance> :NEW <parameters>)

<a_class_instance> is in fact an instance of class CLASS. Class CLASS allows
you to define new class instances by specifying the instance variables and
parent class of a particular class.

** Declaring a class.

To declare a "base class" object, that is, an object with no parent object,
just send message :NEW to the object <CLASS>

        (SEND CLASS :NEW '(<ivar0> ... <ivarN>)
                         ['(<cvar0> ... <cvarM>)])

'(<ivar0> ... (ivarN>) are a list of symbols. Each <ivar-i> names an
instance variable of the class. '(<cvar0> ... <cvarM>)]) are an optional
list of variables that are shared among all instances of that particular
class.

** Defining methods.

When a "message" is sent to an object, XLISP searches for a "method" to
answer the message. A method is a piece of Lisp code that is executed when
a particular message is sent to an object. Within the code of a method, all
object instance and class variables are accessible. Furthermore, the symbol
'self' is bound to the object the message was sent to.

Methods are defined by sending the message :ANSWER to <a_class_instance>:

        (SEND a_class_instance :ANSWER <:msg> <parameters> <code>)

where <:msg> is a keyword symbol (a symbol with a ':' prefix) representing
the message; <parameters> are the arguments given along with the message.
See the documentation on "lambda lists" in /winterp/doc/xlisp.doc p.12 for
details.  <code> is a list of s-expressions which get evaluated in response
to a message. The lexical environment that existed for the call to :ANSWER
will be used for value and functional bindings during method evaluation.

If you need to remember what the syntax is, consider the memory-helper
    "this class :ANSWERs to :MESSAGE..." == (send <cls> :ANSWER :MESSAGE ...)

** Inheritance

So far, the object system we just described supports *encapsulation*.
Encapsulation is good programming practice because it helps localize and
detangle complexity. Unfortunately, encapsulation runs counter to
flexibility because making flexible use of an object may require that
certain groups of instance variables be accessed by different layers of new
functionality. Most often, one wants to *reuse* aspects of a particular
class in creating code that specializes and alters the functionality of
that class. A compromise between encapsulation and flexibility is found by
using *inheritance* in an object system. Inheritance is used to allow a
 *subclass* to specialize the functionality of it's *parent class* (aka,
the *superclass*):

        (send Class :NEW '(<ivar0> ... <ivarN>)
                         '(<cvar0> ... <cvarM>)
                         <superclass>)

(<ivar0> ... <ivarN>) is a list of new instance variables in the subclass;
(<cvar0> ... <cvarN>) is a list of new class variables in the subclass;
<superclass> is a class instance representing the parent from which
the new subclass inherits variables and methods.

"Inheritance" is occurring because all the instance variables of all the
parent classes of the new subclass become the variables of each subclass
instance. Furthermore, all methods defined on a parent class may also be
used on a subclass instance. Note that while a subclass' methods can access
the variables defined on the parent classes, the reverse isn't true.

** Object initialization.

As mentioned earlier, new object instances are created by sending the
message :NEW to a class object. Sending the message :NEW to a class
automatically sends message :ISNEW to the newly created instance. By
default :ISNEW on an instance is a no-op method defined on class 'Object',
which is the implicit [(grand)*]parent of all instances. If you want to
initialize the instance/class variables of a particular class, you must
define an :ISNEW method on the class.  Any parameters originally sent to
the :NEW method will be passed on to the :ISNEW method and may be used to
initialize an object to outside-world parameters.

** Example of using OOP features of XLISP with Motif widgets:

The current implementation of the Motif widget class xmListWidgetClass
makes it less-than-straightforward to create "browsers" of dynamic
information.  The problem is that a "browser" is a kind of application that
lends itself to object oriented techniques that are not always
straightforward to support in C. One often has a collection of 'things'
that one wants to display in a 'list' and perform actions on the 'thing'
corresponding to the visual selection of an element in the displayed list.
xmListWidgetClass will display an array of XmStrings in a list. When one
or more elements in the list are selected, XmStrings corresponding to the
selected elements are returned. Since the XmStrings you put into the list
widget are not the XmStrings you get out, you must call XmStringCompare on
each element of the collection of 'things' to find out which 'thing' was
selected.  Presumably, you'll want to do more than just get back an
XmString...  normally one will want to access data structures associated
with the 'thing' so as to perform an action dependent on those structures.
This could be done with a lookup table, but there's also a better way...

WINTERP allows us to subclass the Motif list widget so as to make it have
the kind of functionality we want. This subclass will contain an additional
instance variable 'items' which is an array of arbitrary XLISP objects to
be displayed in a textual browser made from the list widget. These objects
can have completely different internal representations -- the only
requirement is that they follow the protocol of being able to respond to
the messages :DISPLAY_STRING and :DEFAULT_ACTION. :DISPLAY_STRING returns a
string representation of the object to be displayed in the browser.
:DEFAULT_ACTION is the action to be performed when a list item is browsed
(by double clicking on the item).

The following creates the subclass <List_Browser> from superclass
<XM_LIST_WIDGET_CLASS>:

        (setq List_Browser
                (send Class :NEW                ;create a class inst
                        '(items)                ;new instance vars
                        '()                     ;no class vars
                        XM_LIST_WIDGET_CLASS))  ;superclass

So now all instances of <List_Browser> will contain an instance variable
<items> and will respond to all the messages understood by the
XM_LIST_WIDGET_CLASS. We want our list browser to behave as described
above, so we define an :ISNEW method to initialize instance variable
<items> to the list of arbitrary objects to be displayed.  <items> gets
initialized to an array of objects, the list widget is created, and a
XmNdefaultActionCallback is setup so that a double click will send the
message :DEFAULT_ACTION to the browsed item:

        ;; (send
...

read more »



Mon, 08 Aug 1994 10:11:44 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. ANNOUNCEMENT: Object-Oriented Systems - new object-oriented journal

2. ANNOUNCEMENT: Object-Oriented Systems - new object-oriented journal

3. Compare object-oriented and function-oriented ....

4. Action-oriented vs Object-oriented

5. Object Structures - Building Object-Oriented Software Components with Eiffel- By Jacob Gore

6. The use of the Factory Paragraph versus Class-Object in Object Oriented (OO) COBOL

7. Fix for XScheme/Xlisp object system

8. xscheme object system bugs and fixes

9. Xscheme object context diffs & sample (425 lines)

10. Xscheme, object functions

11. 3rd Conference on Object-Oriented Technologies and Systems (COOTS) - Student Grant Application

12. Is Visual Basic Object Oriented?

 

 
Powered by phpBB® Forum Software