[cap-talk] Composability and RAII

[Rob Meijer]

On Sun, March 6, 2011 04:18, David-Sarah Hopwood wrote:
> On 2011-03-06 02:31, Mark S. Miller wrote:
>> Ok, thanks all. I think I see what I was missing. I was only considering
>> an
>> RAII initializing a stack local variable, where by itself it does seem
>> equiv
>> to try/finally. But since these can also be allocated within objects
>> that
>> are themselves destructed by RAII logic, it composes in a way that
>> simple
>> try/finally does not.
>
> I don't think that this composability argument is valid:
>
> Define a "resource" to be an object abstraction that requires explicit
> disposal. That is, the correctness of the application depends on choosing
> precisely when the object is disposed. For example, if a file handle is
> opened for writing, then closing the handle will flush buffered writes,
> and it is (almost always) important for that to be done at a particular
> time.

I don't believe this definition is correct. 'when' is always important,
its 'before the resource is exhausted'. GC works on a single type of
resource, 'memory' and it makes disposal implicit for that resource only.
RAII in C++ is used for memory, but also for all other resources and it
makes disposal implicit (with some programming effort). With cPython
reference counted GC makes GC based memory disposal work implicitly
without programming effort, and allows for using RAII in order to make
other resources disposal implicit.

> Suppose that we have an outer object that is not a resource, but which
> holds a reference to an inner resource. Then I claim that either:
>
> a) the classification of the outer object as a non-resource was incorrect,
>    because it does require explicit disposal

Using this reasoning breaks a lot of OO basics IMO.

For example, lets say we have an AbstractPriorityQue. In a GC language the
MemoryBasedPriorityQueue would be a non resource while the
FileSystemBasedPriorityQueue may be a resource. This would mean that we
should treat AbstractPriorityQue as a resource (with explicit disposal).
In fact any Abstract* would need to be treated as a resource.

I feel the implicit/explicit argument is flawed. At some level memory
needs explicit disposal. For memory RAII and GC are equivalent. GC
languages choose to make disposal implicit only for memory and not for
other resources. I think GC is a great concept, its just a big shame that
it isn't used as a generic resource management mechanism in the way that
RAII is in CPP. The use of 'finaly' and 'with' are IMHO just hacks to
compensate for the fact that GC is applied just to memory, and as I
explained above, 'finaly' breaks encapsulation principles for deep
resources.