Hi Gerrit,
Gerrit Voss wrote:
>> 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 ?.
It doesn't feel so different from other systems.
> 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.
Hm, true.
> 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
I think the problem with that line is more the length of the names
rather than the fact that there are ->s in there.
You could do something like
FieldContainerFactory *fcf = FieldContainerFactory::the();
for(FieldContainerFactory::StoreIt it = fcf->getStore()->begin();
it != fcf->getStore()->end();
++it)
or
for(FieldContainerFactory::StoreIt it = fcf->storeBegin(); it !=
fcf->storeEnd(); ++it)
to make that more readable.
> 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.
Hm, not sure why. Are you thinking about a non-virtual setFoo? I can't
see that form of override work reliably with a generic access system.
And if it's virtual the Handles should be able to go through the
containers vtable. I don't know if the current design supports that, but
it seems doable.
How important is this? Are you using this right now? I like the
simplicity of the system implemented by putting the intelligence in the
fields.
AFAIR the main area where we had problems with the old system where the
cases where you need access to the old value before it was changed. That
was mainly for refcounting. Do you have other cases that are
hard/impossible without that?
I can also see many cases where the current system that keeps the
get/set dumb and puts the intelligence in the changed() makes more sense
(e.g. anywhere the action depends on more than 1 value).
> 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.
If we need that choice there should be only one place that it goes
through. I'm not convinced yet we need it and pay the price for the
added complexity.
> 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.
Making that more accessible is IMHO a good thing. Having dumb and smart
users is not really a good thing, as that adds another layer before
people can comfortably write extensions, which is one thing we're sorely
missing.
I can see your point for direct access, but if those are one-liners I'd
be ok with it, that makes them easy enough to understand that people can
see how things work.
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
