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
