Vote on RFC 31?

[Steve Lime]

Ugh, not sure but I think we're ok. Looks like loadClass is the worst since it takes a mapObj and a layerObj. The mapObj is only passed in order to pass a labelObj  which doesn't even need it. That should be cleaned up. So I think an update can still work.

For example, for a class:

int updateFromString(char *s) {
  return loadClass(self, self->layer); // assuming we loose the mapObj param...
}

If the class is already part of a layer this would maintain that relationship, and if not self->layer is null and would remain so after update. Does that make sense?

I think creating objects would work as well with or without a parent. Not sure how to implement from an API point of view. Would be cool to add a string option to the constructor so you could do:

  $layer = new layerObj($myMap, $myLayerText);

Although with the updateFromString you could do:

  $layer = new layerObj($myMap);
  $layer->updateFromString($myLayerText);

Steve

>>> Tamas Szekeres <szekerest at GMAIL.COM> 06/20/07 1:42 PM >>>
Steve,

I've read the proposal again, but I'm still uncertain a bit about the
actual implementation.  Currently most of the load[Object]s have
various kind of additional parameters like references to the parents,
direct references to the mapObj or additional parameters, therefore
it's not too trivial to treat that objects as separate entities. Are
you planning to eliminate the need of these parameters?