Vote on RFC 31?

[Tamas Szekeres]

2007/6/22, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> 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?

Yes, I think that the load[Objects] should deal with the properties
related solely to that object. The properties related to the external
context should be set externally. For example  loadLayer should be
responsible to set the back reference of the class object to that
layer object (currently loadClass does this job)

>
> 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);
>

Yes it makes sense, if updateFromString will leave the properties of
the parent-child relationship unmodified.

Best regards,

Tamas