avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dert ertytr <krage_2...@yahoo.com>
Subject Re: [RT] Distant Future...
Date Thu, 24 Jul 2003 03:45:53 GMT
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 <bloritsch@apache.org> wrote:
> Leo Sutic wrote:
> 
> > 
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> 
> >>
> > 
> >>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:
> dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail:
> dev-help@avalon.apache.org
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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


Mime
View raw message