On Jul 21, 2010, at 8:16 AM, James Carman wrote:
> On Wed, Jul 21, 2010 at 9:14 AM, Matt Benson wrote:
>> 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 be
On Wed, Jul 21, 2010 at 9:14 AM, Matt Benson wrote:
> 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.
>
Yeah, but what happe
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 car
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.
On Tue, Jul 20, 2010 at 2:43 PM, James Carman
wrote:
> On Tue, Jul 20, 2010 at 2:36 PM, Matt Benson wrote:
On Tue, Jul 20, 2010 at 2:36 PM, Matt Benson 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
On Jul 20, 2010, at 1:01 PM, James Carman wrote:
[SNIP]
> I have also been thinking a bit about
> how to best create proxies to things that have to be looked up (such
> as Spring beans) when they're deserialized. Basically, you need to
> use the writeReplace()/readResolve() mechanism so that you
