Proposal: Automatic Resource Management

Stefan Schulz schulz at e-spirit.de
Sat Mar 7 09:51:21 PST 2009


Stephen Colebourne wrote:
> I think this is understood, however the reality is that it will be. As
> soon as the ARM code is in the compiler, an open source project will
> appear with code to wrap other classes to make them work with the ARM block.
 >
 > Of course that doesn't mean ARM is good or bad, just that we should be
 > realistic about how widely used it will be.

I completely agree. Whatever tool a programmer is given, he or she will 
apply it for good and bad.

> However, with closures officially defined as 'out' I have to choose
> between solving real issues now (in the 80% case) or waiting another 3
> years+. I choose pragmatism - solve the 80% now with ARM, and reconsider
> BGGA/JCA later.

To me, ARM does not come even near 80% of the cases I would like to see 
being solved and what BGGA/JCA could provide. It's a somewhat the least 
common denominator of the desired solution. Together with for-each, it 
will introduce yet another language level control for solving a niche of 
problems. (That does not mean, it's a bad idea.)

In the discussion about whether to use a language level (finally) or API 
level (interface) solution, the siginficant problem I see is the reuse 
of an existing interface/signature. As some pointed out, existing 
classes that have or comply to such an interface may not be ready for 
this kind of usage within a try() statement, although they can be 
applied. My first reaction was to prefer the language level solution, as 
no existing class can be used without re-considering its use in that new 
statement. But a newly introduced interface having a method most likely 
not matching existing ones for resources would nearly have the same effect.
I would also oppose to allow multiple interfaces because of the above 
reasons.

Stefan



More information about the coin-dev mailing list