I used to be thinking about IoC container design, so if someone is interested and want to comment it is at http://freeroller.net/page/terminus. Thanks Krage
--- Berin Loritsch <[EMAIL PROTECTED]> wrote: > Leo Sutic wrote: > > > > >>From: Berin Loritsch [mailto:[EMAIL PROTECTED] > > >> > > > >>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. > > Most of those features should be moved out of the > core container > so that they can be applied accross the board. If > someone else > does a better job for that feature, then just plug > it in. > > We are taking steps to move this direction, albeit > baby ones. > > > > > At the same time, using these features aren't > trivial, so the > > component writer had better understand a lot. > > That is my primary concern. > > > > > 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? > > They will probably change form in the future. In > Fortress/Merlin, > the actual "Pool" classes are divorsed as much as > possible so that > we can have more leeway in that respect. > > > > > 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). > > I personally don't like that, but the async init was > designed for > a reason. Again it is a feature that could be > plugged in. > > > > > 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*? > > :) > > All features exist for a reason. The main issue > here is that > the feature may not be required by all users. > > > >>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. > > Take a look at my long "musings" email. You have > the general idea: > "container kit". There is a method to my > madness--but for the time > being lets focus on the fish frying at the moment. > We have a current > set of requirements that we need to identify and > simplify. > > -- > > "They that give up essential liberty to obtain a > little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
