avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [RT] Distant Future...
Date Wed, 23 Jul 2003 16:49:58 GMT


> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> 
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message