Uninject!

[dtyrell]

Hi Josh,

Is there any way to "uninject"? I just realized that I need to be able
to null any properties that I've injected into at a later point (for
GC).

If not, I see at least two possible routes:
1. injector.uninject(targetInstance): where it nulls properties for
any injection rules it has.
2. injector.cleanup(targetInstance): where it nulls all properties
with the [Inject] annotation.

The first would only make sense if Partial Injection were possible.

What are your thoughts?

Thanks,
Shaun

[Josh McDonald]

Mmmm, not sure about that. It could be done with scoping or sub-injectors, if we had them :D

2009/4/17 dtyrell <Dar...@gmail.com>

--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

Josh 'G-Funk' McDonald
  -  jo...@joshmcdonald.info
  -  http://twitter.com/sophistifunk
  -  http://flex.joshmcdonald.info/

[darscan]

Perhaps a static utility method that simply "nulls" all properties
that are annotated with [Inject] for the instance passed to it?

Something like: SmartyPants.clearValues( obj );

Sorry for all the questions/suggestions/requests.. Every now and then
I explore the SmartyPants source, but I haven't had a chance to site
down and try make sense of it all.

Cheers,

On Apr 18, 4:42 am, Josh McDonald <j...@joshmcdonald.info> wrote:
> Mmmm, not sure about that. It could be done with scoping or sub-injectors,
> if we had them :D
>

> 2009/4/17 dtyrell <Dars...@gmail.com>

>
>
>
>
>
> > Hi Josh,
>
> > Is there any way to "uninject"? I just realized that I need to be able
> > to null any properties that I've injected into at a later point (for
> > GC).
>
> > If not, I see at least two possible routes:
> > 1. injector.uninject(targetInstance): where it nulls properties for
> > any injection rules it has.
> > 2. injector.cleanup(targetInstance): where it nulls all properties
> > with the [Inject] annotation.
>
> > The first would only make sense if Partial Injection were possible.
>
> > What are your thoughts?
>
> > Thanks,
> > Shaun
>
> --
> "Therefore, send not to know For whom the bell tolls. It tolls for thee."
>
> Josh 'G-Funk' McDonald

>   -  j...@joshmcdonald.info

[Josh McDonald]

To be honest, I just can't see any use for "uninjecting" something that couldn't be be better done with clever use of live injections. What exactly are you trying to achieve?

2009/4/19 darscan <Dar...@gmail.com>

  -  jo...@joshmcdonald.info

[darscan]

Yes, agreed, it's very specific to my problem, and a solution probably
wouldn't be useful in many other scenarios.

For example, the Presenter pattern wouldn't have this problem, as any
view component that leaves the stage, and has no other references,
would get GC'd - in turn freeing it's Presenter.

With the Mediator pattern however, a view component doesn't have a
reference to it's Mediator. Instead, the Mediator has a reference to
it's view, and the view is kept blissfully unaware it's Mediator (and
the rest of the application).

Ideally, the Mediator should only be kept alive by a reference in an
external Dictionary that uses the Mediator's View component as a weak
key. Then, when the view component leaves the stage (again, assuming
there are no other refs to it), it will get GC'd, and due to it being
a weak key in the Dictionary, the Mediator will get freed as well.

But: the Mediator still has a ref to the view (the one that was
injected), keeping the view key in the Dictionary, and in turn keeping
the Mediator alive. I have to null the Mediators ref to the view to
let the GC do it's thing.

Anyhow, I'm sure I can solve it pretty easily with the SmartyPants
Reflection util. I just thought that nulling all dependencies might be
useful outside of my problem, but perhaps not so much!

Cheers!

On Apr 19, 10:12 am, Josh McDonald <j...@joshmcdonald.info> wrote:
> To be honest, I just can't see any use for "uninjecting" something that
> couldn't be be better done with clever use of live injections. What exactly
> are you trying to achieve?
>

> 2009/4/19 darscan <Dars...@gmail.com>

[Josh McDonald]

Player uses a mark-and-sweep on allocate, as well as constant
reference counts, so if the only strong references to two objects
originate from each other, they will still get collected, so there's
no need to worry about that.

-Josh

Sent from my iPhone