Changes between Version 3 and Version 4 of Notifications

Timestamp:

Jun 19, 2015, 5:12:48 PM (10 years ago)

Author:

Eric Pettersen

Comment:

--

Notifications

@@ -14 +14 @@
 == Data Changes
 
-Again, this will be similar in many ways to Chimera 1.  Changing the color of an Atom will put that Atom in the "modified" set of Atoms and add "color changed" to the list of Atom reasons.  A significant difference from Chimera 1 is that instead of firing individual Atom/Residue/Chain/etc. triggers, one "atomic data" trigger will fire that has keys of Atom/Residue/Chain/etc. and values that contain the reasons, the sets of create/modified atoms, and possibly the set of deleted atoms.  This eliminates timing issues of which trigger should fire first and eliminates the possibility of changes by trigger handlers "infiltrating" later single-class triggers.  Such changes will instead accumulate into the next firing of the atomic-data trigger.
+Again, this will be similar in many ways to Chimera 1.  Changing the color of an Atom will put that Atom in the "modified" set of Atoms and add "color changed" to the list of Atom reasons.  A significant difference from Chimera 1 is that instead of firing individual Atom/Residue/Chain/etc. triggers, one "atomic data" trigger will fire whose associated data is a dictionary that has keys of Atom/Residue/Chain/etc. and values that contain the reasons, the sets of create/modified items, and possibly the set of deleted items.  This eliminates timing issues of which trigger should fire first and eliminates the possibility of changes by trigger handlers "infiltrating" later single-class triggers.  Such changes will instead accumulate into the next firing of the atomic-data trigger.
+
+The sets of created/modified items are collections, not lists of individual Python objects.
+
+As usual, the deleted items is the tricky part.  My proposal is this:  The deleted items is a list containing all the individual Python objects that had already been created at the time they were deleted, plus a sufficient number of Nones to bring the size of the list up to the total number of deleted items.  My reasoning is that no code is going to care about individual deleted Python objects that had never been created when they were deleted.  Keep in mind that collections automatically contract when their members are deleted.  I propose we add a callback API to collections so that interested code can respond to such a contraction if desired.