> From: Berin Loritsch [mailto:[EMAIL PROTECTED] > > a nice reference to what you are > referring to the first time would help.
You are right. Point taken. In this case, http://www.picocontainer.org is the proper site to check. > I would prefer something that didn't require a try/finally > approach because we are imposing too much on the developer. > Remember simplicity--and the question becomes for who are > things simplified? For container and component writer, I think. As it is now we have a lot of features in the containers making them hard to write. At the same time, using these features aren't trivial, so the component writer had better understand a lot. Take Fortress's async release of components. The only reason we have that is because we support transient and poolable object (only really the latter). Do we really need transient and poolable components in the shape & form we have now? Take Fortress's async init - the first feature request for the init sequence was to be able to run it in the main thread (init = inline). So my question is this - are all those features really needed, or are they just patches on top of a contract that simply put promises to do too much? Can we simplify things by promising *less*? > My version of simplicity will allow the container to adapt > so that there are very little real requirements on the > component writer. Would this be similar to the subsystem approach that WinNT has? I.e. you have an NT kernel, and then you can run a Win32 subsystem on top of it, a POSIX subsystem, etc.? This sounds much like a containerkit. If there are few requirements on the component writer, then there must be more requirements on writing that subsystem - after all, I'll never be able to just throw random code at the container and have it figure everything out automagically. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
