RE: [picocontainer-dev] Bug in DefaultPico?
"Michael Rimov" <[email protected]>
| Newsgroups | gmane.comp.java.picocontainer.devel |
|---|---|
| Organization | Centerline Computers, Inc |
| Message-ID | <009301c84248$114963c0$33dc2b40$@com> |
> -----Original Message----- > From: Paul Hammant [mailto:[email protected]] > Sent: Wednesday, December 19, 2007 4:25 AM > To: dev-qxt/[email protected] > Subject: Re: [picocontainer-dev] Bug in DefaultPico? > > Mike, > > > > >> You're quite right - its lame as is. > >> What do you think it should be changed to ? One using plain refs > >> rather than > > integers ? > > > > I don't see why we shouldn't use plain refs. As long as the refs > > are cleared > > after dispose() -- I mean, perhaps something else will show itself > > as a better > > option later, but for now, I'd take care of one step at a time. > > Oh yes I remember. It was to do with garbage collection. If they are > in a list/set as refs then they are likely to be prevented from being > eligible for GC. I can't remember why that would ever arise ... I > mean when you'd want to dispose of CAs but not the container that > contained them.. :-( Yeah, I was thinking about that -- Let me play with it for a day or two and I'll try to come up with a properly encapsulated alternative. > > I'm also thinking of moving the start, stop, and dispose operations > > to a > > Visitor. (The visitor doesn't have to be transient, so it would be > > possible for > > it to keep track of what CA's and what Child containers were > > started.) It > > should help move several of the additional data structures sitting > > in Pico to > > other more reusable objects. > > Meh. > > With Pico2 I deleted Aslak's visitor abstraction and lifecycle impl of > it. I did not like the way that from root it would traverse the > entire tree. > > With Pico, you can chain containers together. Each in a parent, > child, grandchild situation might have a different set of behaviors > incl lifecycle. By each Pico instance delegating to the next's > start() methods, there a decent mechanism to subvert the traversal. I > think that superior - even though its slightly more code. True -- And even then I never thought about traversing child containers. But since there's so much data being used to handle lifecycle events, I still think that the behavior needs to be encapsulated. I'll work up a proposal and post the diff to jira. -Mike --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email