-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
To all:
This is the beginning of a discussion about what I called meta-level usage of the Cells approach and mechanism actually using Kenny's Cells package. You better start at the bottom to get this straight then go up again and read downwards <g>
Here we go:
Am 24.05.2005 um 00:30 schrieb Kenny Tilton:
Frank Goenninger - PRION Consulting wrote:
Kenny,
while designing my app here I am stuck with the following problem:
Using Cells I want to build an object management kernel (to be used within my Product Information Management Application). This kernel has to implement a basic set of operations to manage objects (instances of any kind of class) such as Create, Read, Update (using Check-in / Check-Out into / from Vaults) and such.
While Cells is perfect for modeling dependencies between instances of objects (using synapses) I am now about to implement relations and dependencies between classes.
uh-oh, maybe Thomas is right and "synapses" is as confusing as it is clever. And synapses are now just Cells, to make things even worse. :) But I still talk about synapses as a class. Cells model dataflow from one slot of an instance to another slot of the same or different instance. That is, a c-ruled (or is it c-dependent?) can access any combination of other c-ruled or c-input cells. A synapse arises where one wants either to (a) mediate that dependency, say with an f-sensitivity synapse; (b) translate the dataflow, as with a delta synapse; or (c) do either with an arbitrary subform within a cell rule (something I might have pointed out with the new Synapse mechanism, and will shortly in a standalone post).
I think it is worth here to distinguish between two separate domains where the terms CLASS, INSTANCE, RELATION, DEPENDENCY each have different meanings and side effects.
In the Application domain (my app being based on Cells) has Classes that get defined while adapting the app to a user's needs. A typical class would be "BOM" (said bill of material). The other one to be use in the use case outlined below is class "PART".
So we have:
+ Application Class BOM + Application Class PART + Class Relation IS-USED-IN: PART -> BOM (read: a PART can be related to a BOM with the relation IS-USED-IN). This is a relation defined on CLASS (!) level.
+ Instance "As Built BOM, Baseline 001" of application class BOM + Instance "High Pressure Turbine, Serial Nr 0001" of class PART
In order to make the use case more verbose we define some attributes on the classes:
+ Attribute PRICE on class BOM + Attribute NR-PARTS on class BOM
+ Attribute PRICE on class PART
The relation is a "general" one: if any attribute of an instance of class PART changes then recalculate all attributes of the corresponding instance of class BOM.
Several things have to be noted here:
Adding a part to a Bom is done by the following steps (not using Cells but the - say - traditional approach):
0. BOM instance is already there 1. Create an instance of class PART 2. Create an instance of relation IS-USED-IN 3. Set the LHS (left hand side) of the relation to the object id of the new part 4. Set the RHS of the relation to the object id of the BOM instance
Now, the update mechanism in this traditional approach always crawls all relation instances using the id of the changed object to find all other objects being related to that instance id and sends an update event to all these instances.
This should be avoided by limiting the nr of events being fired. Not every related object has to be updated when a part is added. The same is true when the Price attribute of a part is changed: the BOM need not recalculate the nr of parts in it.
The intended use case is:
Define a relation class that says: update attribute PRICE on instances of class BOM if the attribute PRICE of instances of class PART changes - respecting the fact that a particular instance of class PART is always related to particular instances of class BOM (so update only those affected).
A part can be related to more than one BOM. A BOM can have more than one part (well, a simple n:m relation).
So, I want to define a class-level dependency between classes BOM and PART by defining the slots PRICE in BOM and NR-PARTS, PRICE in PART as cells.
Using whatever mechanism out of the Cells package I defined the relation between these Cell slots. As there will be millions of instances of PART and (a few less) instances of BOMs I want to have to define the dependency just once while still being able to overwrite the firing rules and the dependency rules between any two instances of classes BOM and PART.
The reminder of the email exchange is now discussion the various aspects of this and also what Cells really are ;-)
The use case for this will be: I create a dependency between class BOM (bill of material) and Part (individual components). Once having create that class synapse-connection every instance created of the classes BOM and Part "knows" of the dependency ...
A couple of things here.
(1) I myself have lately stepped up my understanding of Cells, viz, that a lot of the power comes from being instance-oriented, as in different instances of the same class can have different rules for the same slot. Note that def-c-output compromises this by being class-oriented, so now I have a solid reason for my long-held vague discomfort with def-c-outputs which are not really outputs but instead feed back into the model by setf-ing c-input cells. So this talk of relations between classes has me thinking "you better have a good reason". <g>
(2) I forget the second thing.
and after being related to specific instance (say, a Part "High Pressure Turbine, Serial Nr 0001" is related to an instance "As Built BOM , Baseline 001" of class BOM) then, when the Part "High Pressure Turbine, Serial Nr 0001" gets changed..
You lost me. Do you mean it gets changed in the sense that some other part is now being used, or in the sense that some attribute of the part (say, the price of the turbine) changes?
Both:
If a new part is added or a part is deleted from the BOM or the price attribute is changed.
the synapse between the two classes triggers the /right/ instance of class BOM, here the instance "As Built BOM , Baseline 001".
"Triggers"? Do you mean, the total on the BOM would have to be changed to reflect the changed turbine price?
Yes.
Anyway, it does not sound as if the two classes require dataflow, it sounds as if each instance of each class will require that dataflow with some other instance.
Agreed.
As much as I talk about instance-oriented programming, hey, if you author a cell in a rule supplied in an initform or default-initarg, guess what? You get class-oriented behavior. :) Just do not override those rules at make-instance time. :)
Aha!
####
It all started with my email:
Kenny,
while designing my app here I am stuck with the following problem:
Using Cells I want to build an object management kernel (to be used within my Product Information Management Application). This kernel has to implement a basic set of operations to manage objects (instances of any kind of class) such as Create, Read, Update (using Check-in / Check-Out into / from Vaults) and such.
While Cells is perfect for modeling dependencies between instances of objects (using synapses) I am now about to implement relations and dependencies between classes.
The use case for this will be: I create a dependency between class BOM (bill of material) and Part (individual components). Once having create that class synapse-connection every instance created of the classes BOM and Part "knows" of the dependency and after being related to specific instance (say, a Part "High Pressure Turbine, Serial Nr 0001" is related to an instance "As Built BOM , Baseline 001" of class BOM) then, when the Part "High Pressure Turbine, Serial Nr 0001" gets changed the synapse between the two classes triggers the /right/ instance of class BOM, here the instance "As Built BOM , Baseline 001".
Hmmm - you, as the expert here, would you:
1) Create a new class of synapses
2) Create a new class of cells
3) Implement a new dependency mechanism
4) Do something else
(and for every case I dare to ask: Why ?) ;-)
- --- EOM (End Of Mail) ---