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]
