Hi,
Gerrit Voss wrote:
> On Sun, 2007-09-16 at 11:07 -0500, Dirk Reiners wrote:
>> Gerrit Voss wrote:
>>> yeah I know that opens another box of things ;-)
>> Let us know what you're thinking, and where you see problems. We see a bunch
>> already, but it's always good to know what you're getting into.
>
> we touched it before, the main issue would be if we want to expose the
> ptr fields for writing again. I don't see the need for it and AFAIK it
> is not really common to do that. And IMHO the generic interface is
> sorted to work reasonably well.
yes, I agree. Additionally I doubt we could make pointer fields that are
part of a child/parent link directly writable, because that needs to be
handled at a level where both involved objects (i.e. parent and child)
are known, hence it can not be done inside the pointer class itself.
> In general I'm fine with the user calling functions to modify the
> fields, either to get them (for value fields) or to change them (for
> ptr fields). Pushing everything (ref/parent/change tracking) into the
> fields will make them quite big again and will require custom
> iterators/accessors (at least for ptr fields, like for you find them in
> std::vector<bool>). To fully exploit this they should then support rtti
> again. Of course you could do it only for certain kind of field, e.g.
> pointer fields.
hm, that might be an option to think about. On the implementation level
pointer fields already are special, so they can do the aspect
calculation when syncing. AFAIK the main motivation for getting rid of
the vtable in fields was that a SFUChar8 would have a big storage
overhead, but for pointers this overhead might be more acceptable...
> Actually I would make all fields private to prevent direct access even
>>from derived classes. Inlining should prevent performance
> penalties.
If we stick to the current interface I agree, it prevents the mistake of
accidentally typing _mfFoo.push_back() instead of going through the
proper methods.
On a related note, can we have editFoo() functions for ptr fields, that
return an EditFieldHandle or are they left out intentionally?
> This way it is clear how a field can be accessed and as this part is
> auto generated complexity does not really matter. And we don't have to
> bloat other classes (like fields) which logically don't really have
> anything to do with it, because what should happen depends on the
> surrounding class (container/bundle/what ever).
So are you arguing here for having the ref/parent/change tracking in the
containers and not attempting to move part of it into the ptrs? Or do
you only want the fields out of the picture, so that they can basically
be just storage?
Thanks,
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
