[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "\"RDP%ALAN.kahuna.decnet.lockheed.com\"%ALAN.kahuna.DECNET.LOCKHEED.COM"@Warbucks.AI.SRI.COM, slug@Warbucks.AI.SRI.COM
- Subject: Statice/CLOS integration.
- From: email@example.com (Stephen G. Rowley)
- Date: Mon, 12 Feb 90 20:22:00 EST
- Character-type-mappings: (1 0 (NIL 0) (NIL :BOLD-ITALIC NIL) "CPTFONTBI") (2 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB")
- Fonts: CPTFONT, CPTFONTBI, CPTFONTCB
- In-reply-to: <9002092246.AA11819@diamond.STC.LOCKHEED.COM>
Date: Fri, 9 Feb 90 16:46:52 CST
[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.
3) Write some macros that expand the features of CLOS you need into
flavors. Dump them when you get CLOS in Genera "for real."
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>
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):
#<Entity-Handle of LIPKIN-TPSHF-PROBLEM 353/7 337621237>, 1an object of flavor LIPKIN-TPSHF-PROBLEM,
0 has instance variable values:
STATICE-MODEL:DOMAIN: #<Domain LIPKIN-TPSHF-PROBLEM 337613200>
STATICE::SCHEMA-TABLE: #<Table 35/50 :LOCKING NIL 337613003>
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