[cap-talk] Composability and RAII

Rob Meijer capibara at xs4all.nl
Sun Mar 20 11:12:52 PDT 2011

On Sun, March 20, 2011 18:10, David Barbour wrote:
> On Sun, Mar 20, 2011 at 3:02 AM, Rob Meijer <capibara at xs4all.nl> wrote:
>> If, as David-Saray claims a resource is anything that requires explicit
>> release, and the property of 'being a resource' is ,as what I understand
>> from what David-Saray claims, transitive to composition, than any form
>> of
>> polymorphism would require the assumption of 'being a resource'. This in
>> term would mean that each and every interface would need to include a
>> 'release()'.
> That isn't the case. Supposing Alice holds a resource, Alice could
> present Bob with an abstraction that accesses the resource but does
> not expose a 'release()' authority. Under these circumstances, Alice
> is holding a resource and Bob is holding some alternative service. The
> property of 'being a resource', hence, is not transitive across
> composition. Resources may be encapsulated by the facet pattern.
> Indeed, the 'with(resource,action)' pattern that obtains the resource
> but hides the facet for releasing it... is, indeed, an example of this
> encapsulation, but limited to stack scope.

The problem arises when Bob has a (the last) reference to Alice.
Bob could not allow this reference to go out of scope without asking Alice
to release any resources Alice may hold.

Lets make Alice a container of some sort, lets say a priority queue. Now
lets say there are two types of concrete classes that implement an
AbstractPriorityQueue. a simple memory only one, and complex distributed
one that holds all kinds of remote and local resources that need to be
explicitly released.  So we have a MemoryPriorityQueue and a
ComplicatedResourcesPriorityQueue. Now Bob has his own
AbstractPriorityQueue that could be either. This basically menas that
AbstractPriorityQueue requires a 'release' method for bob to call before
Bob allows this priority queue to go out of scope.

This IMO breaks encapsulation, this IMO breaks polymorphism.

More information about the cap-talk mailing list