Hi, On Sat, 2007-11-10 at 17:20 -0600, Carsten Neumann wrote: > 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 ?
yes, they are. > 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 ;) no it is not. > > 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; No > they > can be fully edited now, so there is not much need for an interface in > the containers. Just from a technical point of view for the general case. > 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); I don't like this. node->addChild(newChild) is much clearer. And there was feedback that doing a->b->c->d->.... to achieve something is at least awkward. Again a lot boils down to why do we have to make it different from what all other systems do, without a really compelling reason ?. A lot of beginners would expect the containers to have functions to build the object hierarchy. Not having them is at least confusing, as usually these functions provide a good guideline through the system. just one feedback I have at hand (sorry in German) ------ Du erinnerst Dich an mein argument, dass OSG-code "abschreckend" ist -- hier ist noch ein beispiel: FieldContainerFactory::FieldContainerStoreIt fcIt = FieldContainerFactory::the()->getFieldContainerStore()->begin(); FieldContainerFactory::FieldContainerStoreIt fcEnd = FieldContainerFactory::the()->getFieldContainerStore()->end(); Man kann einem neuling nicht klar machen, dass man solch lange zeilen braucht, nur um einen iterator ueber alle FCs zu bekommen ... ------ "abschreckend" ~ daunting > > 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. The problem is the following: The system allows you to override the default setFoo method. So if I want a container (and as containers get more complex this is more likely) to do more during setFoo I can prohibit direct field access and provide mySpecialSetFoo and I'm sure that this is the one always called, even when using the generic interface (e.g. by the loader). Your handle implementation provides a way around this. > 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 ? No, but I want to have the choice. If I want them to go through the container I want to be sure that they do so for every possibility. Preferable without changing the base class code and adding another handle. > What is the rationale for preferring this way ? It is not one way or the other, IMHO both have a valid reason to be there. It is more about making sure that the different possibilities are consistent. And that the general interface follows at least a little bit what users would expect. Similar keeping the direct field access for the more experienced user is not a problem. kind regards, gerrit ------------------------------------------------------------------------- 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
