Hi, On Sun, 2007-09-16 at 11:07 -0500, Dirk Reiners wrote: > Hi Gerrit, > > 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. 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. Actually I would make all fields private to prevent direct access even from derived classes. Inlining should prevent performance penalties. 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). > The WeakPtr semantics say that you cannot access the WeakPtr directly, you > have > to turn it into a RefPtr before you cna use it. You can only onyl do that > while > there are still other references, so a WeakPtr pointing to a dead object will > return NULL, and there is no way to resurrect a dying object through a > WeakPtr > to it. No zombies allowed! ;) ok, that check wasn't to clear before ;-). > >> I'm not too excited about it, as it another area of possible confusion > >> and abuse. if we can find a way to not go behind the back of the refPtr > >> I'd prefer that. > > > > Yes and no, adding a duplicated set of pointers (e.g. the internal > > variants) doesn't sound clear of confusion to me. As we will confuse > > somebody anyway the question than is more whom are we going to > > confuse. > > We talked about that one too, and concluded that somebody who uses a class > named > 'Internal' which has a blinking red warning not to use it cannot be helped. > If > that's the price to pay for not having to deal with manual refcounts I'd be > ok > with it. > > We also thought about hiding them inside the Fields, but that would be > difficult > with the Fields being in Base and would probably complicate some other > things. > We didn't think it through to the very end, but it might be an option. On a second thought as long as they don't obviously jump out it should be ok. 99.9% will be generated code anyway so it shouldn't be to bad. 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
