Hi Gerrit,
Gerrit Voss wrote:
[SNIP - commit log]
> just one clarification, as I saw these again. *Handle classes are not
> there and were never meant to change the field directly.
I thought they were supposed to implement to generic interface for
fields that hold pointers. Are they not ?
For pointer fields there must be a way to read and write the fields
values without having to know the static type of the field otherwise
things like loaders become a lot more tricky, but that is surely is no
news to you ;)
> They either should allow you access to the field (get as it was, edit
> for value fields)
Right, all the virtual methods just down-cast the handle's Field * and
invoke a member function an appropriate member function of the field.
> or call back into the container the field was coming
> from (edit for pointer fields). All the are allowed to do is the initial
> parameter check.
Hm, I guess I made the fields smarter than you intended them to be; they
can be fully edited now, so there is not much need for an interface in
the containers. For example to add a new child to a node, the following
should suffice (well, once I've changed Node to actually use the new
fields):
NodePtr node = Node::create();
NodePtr newChild = Node::create();
node->editChildren()->push_back(newChild);
> Adding a second place that can modify fields is IMHO not a good idea,
> because you would have to introduce special cases every time it is not
> a simple set. And you would have to keep track that once you change the
> class functions you have to change/update the handle classes as well.
No, the handles do not have any smarts whatsoever, they can be thought
of as the type that carries the fields vtable and forwards all work to a
concrete field instance, so there is not really a second place that
modifies fields in a nontrivial way.
Do you want the fields to be "dumbed down" again a bit so that they do
the ref counting, but changes to them still have to go through the
container ? What is the rationale for preferring this way ? (The fields
I checked in provide the same interface for data and pointer fields,
which I think is quite a nice thing to have).
Thanks,
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
