Closed GoogleCodeExporter closed 8 years ago
Original comment by voigtjr@gmail.com
on 23 Jul 2009 at 5:29
Original comment by voigtjr@gmail.com
on 23 Feb 2010 at 7:39
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
Original comment by voigtjr@gmail.com
on 18 Mar 2010 at 7:39
Original issue reported on code.google.com by
voigtjr@gmail.com
on 23 Jul 2009 at 4:33