From pw at snoopy.mv.com Tue Feb 17 07:49:37 2009 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 17 Feb 2009 07:49:37 -0500 Subject: [Gbbopen-list] deleted-unit-instance Message-ID: <499AB261.80208@snoopy.mv.com> The recent side effect of delete-instance changing the class of the instance to deleted-unit-instance and thereby losing all state information was not anticipated here. I have worked around this change by guarding calls to slot references with deleted-unit-instance-p but am not sure at this point how broken my application really is. Having object state available (when the deleted state was just an attribute) was very handy during debugging and letting application code access non blackboard object state of a deleted instance seemed useful. Is it possible for a delete-instance-event handler to intercede and change the class of the instance to preserve non-BB state? Example; if exists non BB class location and a BB class (define-unit-class location-unit (location standard-unit-instance)()) then (delete-instance (make-instance 'location-unit)) results in an object of class location? Paul -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From corkill at gbbopen.org Tue Feb 17 17:36:22 2009 From: corkill at gbbopen.org (Dan Corkill) Date: Tue, 17 Feb 2009 17:36:22 -0500 Subject: [Gbbopen-list] deleted-unit-instance In-Reply-To: <499AB261.80208@snoopy.mv.com> References: <499AB261.80208@snoopy.mv.com> Message-ID: <499B3BE6.4060903@GBBopen.org> Paul Werkowski wrote: > The recent side effect of delete-instance changing the class of > the instance to deleted-unit-instance and thereby losing all > state information was not anticipated here. Paul, We tried to strike a balance between detecting the erroneous use of a deleted unit instance and retaining some debugging information by keeping the original class of the deleted unit-instance and its instance-name as slots in the DELETED-UNIT-INSTANCE object. However, to give you more control over what is retained in a deleted unit-instance object, we've added a new generic function, DELETED-INSTANCE-CLASS used by DELETE-INSTANCE that when called with the unit instance to be deleted, returns the class name (or class object) to be used in the CHANGE-CLASS that DELETE-INSTANCE performs. The default method (on STANDARD-UNIT-INSTANCE) returns the DELETED-UNIT-INSTANCE class. You can define your own subclasses of DELETED-UNIT-INSTANCE (retaining whatever slots you wish) and add method(s) to DELETED-UNIT-INSTANCE to indicate your preferred subclass of DELETED-UNIT-INSTANCE. The new DELETED-INSTANCE-CLASS functionality has been committed to the SVN repository. Documentation for it will follow... -- Dan -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From corkill at gbbopen.org Wed Feb 18 02:43:11 2009 From: corkill at gbbopen.org (Dan Corkill) Date: Wed, 18 Feb 2009 02:43:11 -0500 Subject: [Gbbopen-list] deleted-unit-instance In-Reply-To: <499B3BE6.4060903@GBBopen.org> References: <499AB261.80208@snoopy.mv.com> <499B3BE6.4060903@GBBopen.org> Message-ID: <499BBC0F.4090904@GBBopen.org> One additional note: In addition to deleting a unit instance (and using the new DELETED-INSTANCE-CLASS functionality), there is always the option of using CHANGE-CLASS rather than DELETE-INSTANCE. Changing the class of a unit instance to a class that is a non-unit-instance (not a subclass of STANDARD-UNIT-INSTANCE) has the side-effect of removing the unit instance from the blackboard repository. I think that the new DELETE-INSTANCE functionality is probably clearer when the intent is to actually delete the unit instance (and not access it any longer--except for debugging purposes). On the other hand, using CHANGE-CLASS to change a unit instance into a non-unit-instance is probably clearer as to intent when the objective is to continue to use the object--but no longer have it be a unit instance (and thus also have it removed from the blackboard repository). Another difference between the DELETE-INSTANCE versus CHANGE-CLASS choice is the event functions that are triggered in each case. As always, increased flexibility brings additional programming-style decisions...! -- Dan -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.