Statice/CLOS integration.

[sgr@ai.ai.mit.edu (Stephen G. Rowley)]

    Date: Fri, 9 Feb 90 16:46:52 CST
    From: "RDP%ALAN.kahuna.decnet.lockheed.com"%ALAN.kahuna.DECNET.LOCKHEED.COM@Warbucks.AI.SRI.COM

    [It seemed like others on the SLUG list might be interested in this conversation.  
    Symbolics developers are particularly invited to jump in. :-) ] 

[How 'bout a Symbolics developer on leave? :-]

    Here's a specific example:

    I want to store objects of type 'FOO in a Statice database.  One way or
    another (typically with FOR-EACH), I'll retrieve these objects.  What
    I'll really get back are entity handles (which are Flavor instances
    *not* CLOS instances).  Thus, a CLOS method which takes an argument of
    type 'FOO won't work.  

If by "CLOS method" you mean something like PCL, you're right: PCL and
flavors are not the same thing.  If that's your problem, it has little
to do with Statice, but a lot to do with the fact that PCL is not
"native" to the rest of the system.  When you get a Genera release that
includes both CLOS and Statice, this will no longer be an issue.

I think what your previous respondent meant was that define-entity-type
defines a flavor; the entity handle is an instance of that flavor.  See
the example below, and the Statice manual "Integrating Object-oriented
Programming with Statice," pp. 106-108.

			   Additionally, the Statice-generated accessor
    functions will be Flavor methods not CLOS methods.  I'm not sure what
    the implications of this are.

    I can see two approaches to dealing with this:

    1) Contrive to make Statice deal with CLOS rather than Flavors by
       patching the Statice source.  This seems possible (starting with the
       DEFINE-ENTITY-TYPE macro), but I'm not anxious to try it.

    2) Contrive to map each entity handle into a corresponding CLOS
       instance at run-time.  I think this is what the "put a CLOS layer on top of
       Statice" suggestion means, but I don't really see a nice clean way to
       go about it.

or:
3) Write some macros that expand the features of CLOS you need into
flavors.  Dump them when you get CLOS in Genera "for real."

    Help, anyone?

I have here a Statice application (physics so amazingly boring that you
don't want to know the details) that keeps around a database of things
called Lipkin-TPSHF-problem's.  Lipkin-TPSHF-problem is defined by a
define-entity-type, just as in the Statice documentation.  In addition,
most of the attributes have :cached t, so their values get remembered
even outside transactions.  Thus, for most purposes, I don't need to
distinguish between an ordinary instance and one that happens to be
stored in a Statice database.

Here's an example:

(find-or-create-Lipkin-TPSHF-problem 10 0.6 /4 /4 0.01 1.0 nil)
#<Entity-Handle of LIPKIN-TPSHF-PROBLEM 353/7 337621237>
T

Now, you might be fooled by the way it prints out (#<Entity-Handle ...>
and all), but in fact, it is an instance of the flavor
Lipkin-TPSHF-problem.  Furthermore, in addition to a bunch of
Statice-generated instance variables, my iv's are in there too, one for
each :cached attribute (marked in bold):

(describe *)
#<Entity-Handle of LIPKIN-TPSHF-PROBLEM 353/7 337621237>, 1an object of flavor LIPKIN-TPSHF-PROBLEM,
0 has instance variable values:
  STATICE-MODEL::RID:                   361479
  STATICE-MODEL::UID-WORD-1:            30515
  STATICE-MODEL::UID-WORD-2:            12689450
  STATICE-MODEL::UID-WORD-3:            5263221
  STATICE-MODEL:DOMAIN:                 #<Domain LIPKIN-TPSHF-PROBLEM 337613200>
  STATICE::SCHEMA-TABLE:                #<Table 35/50 :LOCKING NIL 337613003>
  STATICE::%$INVERSE-CACHE:             NIL
2  %$LIPKIN-TPSHF-PROBLEM-N:             10
0  %$LIPKIN-TPSHF-PROBLEM-N-NOT-NULL-P:   T
2  %$LIPKIN-TPSHF-PROBLEM-CHI:           0.6
0  %$LIPKIN-TPSHF-PROBLEM-CHI-NOT-NULL-P:   T
2  %$LIPKIN-TPSHF-PROBLEM-THETA-F:       0.7853982
0  %$LIPKIN-TPSHF-PROBLEM-THETA-F-NOT-NULL-P:   T
2  %$LIPKIN-TPSHF-PROBLEM-PHI-F:         0.7853982
0  %$LIPKIN-TPSHF-PROBLEM-PHI-F-NOT-NULL-P:   T
2  %$LIPKIN-TPSHF-PROBLEM-DELTA-F:       0.01
0  %$LIPKIN-TPSHF-PROBLEM-DELTA-F-NOT-NULL-P:   T
2  %$LIPKIN-TPSHF-PROBLEM-T0:            1.0
0  %$LIPKIN-TPSHF-PROBLEM-T0-NOT-NULL-P:   T
2  %$LIPKIN-TPSHF-PROBLEM-CREATION-DATE:   2843784723
0  %$LIPKIN-TPSHF-PROBLEM-CREATION-DATE-NOT-NULL-P:   T
  %$LIPKIN-TPSHF-PROBLEM-CREATION-DATE-TRANSACTION:   113
  %$LIPKIN-TPSHF-PROBLEM-T0-TRANSACTION:   112
  %$LIPKIN-TPSHF-PROBLEM-DELTA-F-TRANSACTION:   111
  %$LIPKIN-TPSHF-PROBLEM-PHI-F-TRANSACTION:   110
  %$LIPKIN-TPSHF-PROBLEM-THETA-F-TRANSACTION:   109
  %$LIPKIN-TPSHF-PROBLEM-CHI-TRANSACTION:   108
  %$LIPKIN-TPSHF-PROBLEM-N-TRANSACTION:   107