[cap-talk] Composability and RAII

Rob Meijer capibara at xs4all.nl
Sun Mar 20 10:57:16 PDT 2011

On Sun, March 20, 2011 12:31, Ben Kloosterman wrote:
> If you agree with David conclusions ( and they seem correct)  its also
> wrong
> in  RAII/ C++  ... And it doesn't break encapsulation / polymorphism  in
> general only for the specific case for resources that need to be quickly
> closed ( and hence explicitly) , which for a  few classes  is no big deal.

And for any interface that could for any conceivable or unconceivable way
be implemented in such a way that it uses such a resource internaly. So if
you accept David-Sarah's premise, this basically means that either:

1) Give up on encapsulation/polymorphism
2) Make any abstract (interface) into a resource just in case.

IMO it all comes down to what abstraction do we want to keep.
Either we give up on the 'eternal objects' abstraction for garbage
collection, or we give up on encapsulation and polymorphism.
I would definetely opt to give up on the 'eternal objects' abstraction,
the price we pay for it (encapsulation and polymorphism) is simply to

Its kind of sad, that in Java, that offers us a rather good 'free'
resource management for memory, you will end up actualy writing and
thinking more about resource management than in C++, a language that
doen't even implement the simplest form of garbage collection for the
simplest resource (memory).

I think we need to face the simple fact, the 'eternal objects' abstraction
was a mistake. C++/RAII shows that all types of resources can be properly
encapsulated and can keep polymorphism intact. These lessons need to be
taken back to GC languages, so we can do proper 'resource' management
rather than making things easy for just 'memory'. IMHO memory, file
handles, database connections, threads, diskspace, and even locks are
simply resources that can get exausted. A lock is simply a resource pool
of one.
In retrospect, fixing resource management for only one of these resources
seems to have been a mistake. The distinctions between resources that are
more scarse than memory and resources that are not is artificial and
results in nullifying the positive efects of automated memory management.

More information about the cap-talk mailing list