Hi Carsten,
Carsten Neumann wrote:
>
> I thought they were supposed to implement to generic interface for
> fields that hold pointers. Are they not ?
I thought so, too, but maybe we were thinking too far. ;)
> 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);
Personally I like that a lot. It offers a user interface that looks a
lot like a standard class/STL interface without giving up the featurs
that we want (change tracking, ref counting, ...).
> 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).
Yup. Consistency is always good.
Gerrit, do you see a problem with Carsten's approach? If we can make it
work consistently everywhere I think ti would make for a much cleaner
user experience.
Yours
Dirk
-------------------------------------------------------------------------
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
