[cells-devel] Meta-level oof relations ... How?

[Frank Goenninger DG1SBG]

-----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) ---
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iEYEARECAAYFAkKSa34ACgkQfYXhf9DGKdZlQQCfSOuHaMxVtJbtOGv/Jk7efALw
XXkAnimcQTvB4hq32b3XvXCOcyscVV94
=eoZc
-----END PGP SIGNATURE-----