[cap-talk] Composability and RAII

[Rob Meijer]

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()'.

IMO this very premise is thus in sharp contrast with the base principles
of polymorphism and encapsulation. In C++ RAII shows that you can choose
for polymorphism and encapsulation by making all resources (not just
memory) release implicit, while Java without distructors and with its
'finaly' shows you can choose to distinguish between implicitly released
resources (memory) and explicitly released resources that are transitive
to composition (that is, anything (potentialy) implemented using a
resource that requires an explicit release becomes something that requires
an implicit release.

That basicaly means any abstract (interface) class would require to be
implemented somethinf like:

class Resource {
  public:
     void release()=0;
};

class AbstractFoo: public Resource {
  public:
     void someMethod(...);
};


Thus David-Sarahs claim seems to be right when we assume Java to be right
in the way it offers resource management. I however feel that the fact
that Java choose to offer resource management only for memory makes us
paying a verry large price for the automatic implicit resource management
for memory, the break down of polymorpism and encapsulation.



On Sun, March 20, 2011 08:42, David Barbour wrote:
> On Sat, Mar 19, 2011 at 11:54 PM, Rob Meijer <capibara at xs4all.nl> wrote:
>> The problem is that IMHO if David-Sarah is right , than polymorphism is
>> wrong. At this moment I am not yet willing to accept that.
>
> I do not believe your humble opinion is correct, but perhaps you could
> explain to me your logic?
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>