sleyzerzon / soar

Automatically exported from code.google.com/p/soar
1 stars 0 forks source link

Add method to create or update wmes #20

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Description From Bob Marinier 2007-05-26 11:53:31 (-) [reply]
Currently, a common coding pattern looks like this:

if(wme doesn't exist)
  create wme
else
  update wme

Doug suggested adding a method along the lines of CreateOrUpdateWME that 
would
simplify this kind of code.

Original issue reported on code.google.com by voigtjr@gmail.com on 23 Jul 2009 at 4:33

GoogleCodeExporter commented 8 years ago

Original comment by voigtjr@gmail.com on 23 Jul 2009 at 5:29

GoogleCodeExporter commented 8 years ago

Original comment by voigtjr@gmail.com on 23 Feb 2010 at 7:39

GoogleCodeExporter commented 8 years ago
I am thinking about closing this bug with WONTFIX because it is a bit more 
complex than it seems and might make the current SML 
interface more confusing.

The bug is asking for a CreateOrUpdate method to replace this common pattern:

  * I need to update an element (such as sml::StringElement*), is the pointer null?
    * Create using agent or parent identifier, save element pointer
  * Is it not null?
    * Update using element pointer

Keep in mind that Update is really a shortcut to Destroy one WME and Create a 
new one with the same identifier and attribute (and 
potentially value, depending on settings), changing the timetag of and value 
returned by the containing element object (such as 
sml::StringElement*). 

Having a CreateOrUpdate method available would change the pattern above to this:

  * CreateOrUpdate using agent or parent identifier

But how do we refer to the WME to update here? One obvious way would be by 
using the identifier and attribute, but can this easily 
support multi-attributes? Do we just assume that if an element is found with a 
matching id and attribute to update (delete) it? Saving 
timetags could be an ugly way to work around this.

Another way around this is to create some kind of container object, say 
ManagedStringElement, but we run in to a similar Create/Update 
process:

  * During initialization:
    * Create managed elements, optionally declare initial values
      * Elements without initial values are not created
    * Save the managed element pointers
  * During run:
    * Update using managed element pointers

One thing that the ManagedStringElement buys us is the ability to define the 
structure during initialization and fill and create that 
structure with values as they become available later, where in the original 
(current) design the values must be available (or a default value 
substituted) and WMEs created during definition. Identifiers are a bit more 
tricky (create immediately or wait for valued children?) but 
could be worked around.

I am interested in thoughts and ideas on how to implement a CreateOrUpdate 
method while maintaining backwards compatibility. I feel 
like these wrapped objects could make the interface a bit more confusing than 
their worth permits given how quickly this can be 
implemented by client applications that need it.

Original comment by voigtjr@gmail.com on 24 Feb 2010 at 7:35

GoogleCodeExporter commented 8 years ago

Original comment by voigtjr@gmail.com on 18 Mar 2010 at 7:39