commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [flyweight] WAS [proxy] 2.0 WAS Re: a bit of commons-style code in search of a home
Date Wed, 21 Jul 2010 13:14:01 GMT

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
> <james@carmanconsulting.com> wrote:
>> On Tue, Jul 20, 2010 at 2:36 PM, Matt Benson <gudnabrsam@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message