Feedback and comments on ARM proposal

[Neal Gafter]

On Sun, Mar 15, 2009 at 10:14 AM, Joshua Bloch <jjb at google.com> wrote:
> Neal,
> Sorry if I wasn't clear.  The proposed construct is aimed at types with a
> single termination method that must be called when the program will never
> use the resource again.  The purpose of the document is to enumerate the
> many existing types that fit this usage pattern, so that we can assess the
> applicability of the construct to these types, and tune it if necessary.
> If a type doesn't fit this usage pattern but you think it belongs in the
> document, it should be placed below the line. The
>  java.util.concurrent.locks.Lock type doesn't fit the pattern because it is
> reused after it is "terminated" (unlocked). The
> java.util.Iterator&AutoDisposable type doesn't fit the pattern because it
> isn't found in any existing Java APIs.
>     Regards,
>     Josh
> P.S. The notations [1] and [2] were designed to identify types that appear
> to obey the above usage pattern but aren't important for other reasons.

It sounds like this may be conflating the solution with the problem.
I think what you're saying is that the proposal is restricting itself
to the RAII pattern for resources - where there is some value that is
a stand-in for the resource being held.  In virtually all cases the
true resource itself requiring mediation - O/S file handles, physical
memory, etc - can and often is reused, and the intent of resource
management is to mediate the reuse of the resource.  Streams, for
example, need to be closed so that O/S resources such as file handles
can be reused.  FileLock represents exclusive access to a file, and is
implemented using an RAII pattern, but the resource (the file)
certainly can be used again by the program.  And so on.  Locks are
indeed resources where assistance in mediation is helpful, they just
don't happen to be implemented using the RAII pattern.

Locks do, however, satisfy the definitions in the document. [1] Best
practice demands that the resource typically has a "lexically scoped
lifetime"  (i.e., its close/dispose method should be called when
execution exits the scope in which they were acquired).; and [2] The
type is widely used in practice.  (Roughly speaking, at least
thousands of programmers use it on a daily basis.).  This definition
is more useful than the criteria in your mail, above, as it allows us
to more accurately measure the proposal's applicability.  Use cases
should not be excluded from consideration simply because they aren't
well supported by the proposal.

If you have comments on the various use cases, it is probably best to
place them below the use cases for consistency.  I've already noted
that Locks are not implemented using the RAII pattern.

Any type that extends Iterator&AutoDisposable certainly does satisfy
either definition of a resource, though it should (and is) annotated
with a [2] to indicate that the type AutoDisposable doesn't exist yet
and therefore isn't yet used.  I've also noted that in the
description.  But that's not how it is described by the title bar you
placed above it.