Hi, On Mon, 2007-09-17 at 14:17 -0500, Carsten Neumann wrote: > 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.
as long as you don't store that information somewhere yes. That was the getting bigger part below, as you can let the field know the containing object. > > 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? currently it is intentionally left out of the public methods, as are all the generic getX/editX methods. Mainly for the reason that if you know the object you can call the correct functions to manipulate the field. If you don't know the object you have to call editField(FieldId) anyway and that returns the edit handle (for everything except parent fields). Using a single method for the direct and generic interface is what gave us some headache in 1.x so I tried to avoid it this time. > > 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? Kind of, I'm more looking for some consistency. Something along the lines of if you need functions to access fields correctly the fields should be private and only accessible through those. If you can access them directly (including derived classes) it should be save to do so. The second would require blowing up all fields, except if you want to distinguish different (e.g value/pointer/whatever) fields. I know we distinguish fields (value/ptr) already so this is meant more on the beancounting level. Similar IMHO it would be good if derived classes use the same interface as external classes would, so the difference between external and internal code becomes quite small (you additionally get some protected interfaces) and you don't have to worry to much about things if you need to change some of the beancounting. The rest mainly just follows. If you expose the fields directly they should handle everything needed. If you don't I don't see a good reason to force things onto them. Actually I like the split right now, with the exception that the fields should be private (I might give this one a try and see what happens). Note that the RefPtr are slightly different because besides the functional element they have a structural element you want to expose to the user. And as we allow direct read-only access to all fields this structural element should be stored inside the field. Furthermore because of the structural element the functional part does not have to be handled by the field, so the field itself does not change. kind regards, gerrit ------------------------------------------------------------------------- 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
