You are viewing an old version of this page. View the current version.
Compare with Current |
View Page History
Rationale
It can be difficult to manage resource lifetimes, especially when laziness is involved. Simply local scoping can be inadequate. Resource scopes can decouple resource lifetimes from creating scope.
Plan
- Generalize from resource scopes to general scopes (succeed/fail/exit)
- with-open et al make scopes
- Some design work and code has been done
- find it and write it up
- scope work in streams branch
Use Cases
- REPL usage: open stream and it closes before I lazily consume it. Doh!
- Start an activity, and then have nested resource lifetime automatically tie to it
- Task A calls Iib B which allocates resources
- Prevent resource lifetimes from nesting
- lib C knows it doesn't want its lifetime governed by Task A
- All works across threads
Issues
- Consider threads as well as nesting
- How do scopes interact with io! and stm
- Can we hydrate the fork/join tree where we need it?
- How to prevent mess?
- (when-scope :fails ...) et al are very declarative
- but are setting up non-local effects
- potentially leading to wtf when triggered
- is this the right external API?
- any way to ensure correctness
- will we be beset with requests for order control
- Is the nearest enclosing scope always the right one?
- what to do if not
- named scopes
- scopes as args
- what to do if not
Labels: