Dirk Reiners wrote: > Hi Allen, > > Allen Bierbaum wrote: >> Carsten: >> >> I appreciate the detailed description. I think I have to read it a few >> more times to fully grasp the internal details. >> >> What I think would be useful would be to describe the the user-level API >> would look like. For example, will a user application only use >> RefPtr's? Will these handle all the internal details automatically? >> How will user apps handle aspects or will this be hidden? When the user >> needs a true cptr, how will they get them. >> >> I guess what I am saying is that I am asking a much simpler question of >> what will everything look like to users. I am just trusting that you >> and Dirk will be able to get everything working correctly internally. :) > > I can try to take a shot at that, given that there are a lot of my > Christmas wishes in there. ;) > > Applications would be forced to use RefPtrs to store the values they get > back from the factory or ::create. That way we can be sure that at least > one RefPtr is used and at least one ref is there. > > Internally apps would be strongly encouraged to use RefPtrs to store > FCs, but we won't enforce it. .get() will give you a regular C ptr if > you want it. It's recommended to do that for passing parameters or for > temporaries (as long as there is a guaranteed other ref) anyway. > > Aspects won't be hidden. RefPtrs are only valid in the aspect they were > initialized in. I was planning on enforcing that, but it might make > sense to have a test in there for debugging purposes. > > To go between threads you would have to use a MTRefPtr. That one behaves > pretty much like the current FCs: whenever it is dereferenced it returns > a CPtr for the current thread's aspect.
These last couple points seem pretty nasty to me. Just to be clear, this means that I can't use RefPtr's like I do today. For example I can't just store a RefPtr as a member of an application object and then have that object call the opensg object from whatever thread it happens to be executing within? This seems like a pretty severe limitation to me. I would think we would want the recommended user handle (RefPtr) to "just work" in all cases. > So the impact on user code except for the forced RefPtr at the beginning > should be minimal. Don't RefPtr's currently work in any aspect they are used. IIRC they are and changing this would break most all of our applications. > So far we haven't looked at the CoredRefPtrs. Are you using those? I > don't they need any changes, but if there are ways to make them better, > no is the time to do it. I am using those, but I think they can be ported over very easy once the recommended user handle type is selected (RefPtr or whatever). -Allen > > Dirk > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
