On Jul 21, 2010, at 7:10 AM, James Carman wrote: > The one problem with creating an instance is that the flyweight needs > to be able to get back to his "home" to reconstitute the object. If > it's some instance floating around, that's harder. >
That's why I had thought the flyweight would carry a reference to his object as well as to his container. If the container is no longer accessible by virtue of its static mapping being held only weakly, game over. -Matt > On Tue, Jul 20, 2010 at 2:43 PM, James Carman > <ja...@carmanconsulting.com> wrote: >> On Tue, Jul 20, 2010 at 2:36 PM, Matt Benson <gudnabr...@gmail.com> wrote: >>> I know what you mean; it's potentially not that much code. Maybe start in >>> the sandbox and, once everything's working satisfactorily, decide what to >>> do with it? As for memory, what if you actually put the map of flyweight >>> id:instance onto a Flyweights class and managed *its* id mappings >>> statically/weakly? Then a given Flyweight would just become expired >>> whenever its owning Flyweights instance () was no longer accessible, and >>> its getObject could reflect that somehow. Typically it would be a sign of >>> a programming error if a Flyweight associated with a given container were >>> used after its container had been reclaimed, so a simple exception might be >>> enough. Just ruminating... >>> >> >> Interesting thought. I'll have to churn on that one a while. >> Basically what I'm trying to do is come up with a nice re-usable way >> to solve the writeReplace()/readResolve() problem so that most folks >> can understand it. I can see having a superclass that automatically >> registers a Flyweight for itself and spits that out in its >> writeReplace() method. Then, when anyone wanted that functionality, >> they could extend that superclass. >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
