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