Feedback and comments on ARM proposal (original) (raw)

Neal Gafter neal at gafter.com
Sun Mar 15 10:45:46 PDT 2009

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.

More information about the coin-dev mailing list