Automatic Resource Management, V.2
jjb at google.com
Tue Apr 21 11:17:19 PDT 2009
Thanks! This seems like the obvious correct solution. I feel like a fool
for not having done it that way in the first place.
On Tue, Apr 21, 2009 at 10:24 AM, Tom Ball <tball at google.com> wrote:
> My "vote" (I realize this isn't a democracy :-) is to avoid adding any new
> rules, but instead keep it simple: resources in source code go into all
> tables like any other local variable currently does, while any
> compiler-generated temporary variables get flagged as synthetic and are
> included in any tables that include synthetic variables. In other words, a
> resource should be treated exactly like a local variable already is,
> synthetic or not. A resource is a local variable, after all, just one that
> has some automatic cleanup as it leaves scope.
> BTW, I like Bruce Chapman's suggestion that the type of a temporary
> be AutoCloseable. Since the only thing the compiler generated code will do
> with that object is call its close() method, there's no advantage to it
> having additional type information.
> On Tue, Apr 21, 2009 at 9:48 AM, Neal Gafter <neal at gafter.com> wrote:
> > On Tue, Apr 21, 2009 at 9:12 AM, Rémi Forax <forax at univ-mlv.fr> wrote:
> > >
> > >> You can probably avoid this mess by being explicit about the
> > specification
> > >> rather than attempting the "as-if" rewriting. If a construct like
> > is
> > >> to be integrated into the JLS that would probably be required anyway,
> > and
> > >> a
> > >> new set of issues is likely to be exposed by the attempt. It would be
> > >> better to get the specification wrung out earlier rather than later (I
> > >> don't
> > >> think Alex will be eager to do it himself).
> > >>
> > >>
> > >>
> > > Why the local var need to be visible in these tables ?
> > >
> > > The compiler already introduced new local var , by example, in case of
> > > ++/-- and
> > > compound assignments on boxed type (using the hidden instruction
> > LetExpr).
> > > In that case the local var is flagged SYNTHETIC and doesn't appear in
> > local
> > > vars tables.
> > Right: if the specification is spelled out, one can decide on a
> > case-by-case
> > basis how to handle the mapping to the class file. However, you can't
> > these variables appearing in the verifier tables at the very least. In
> > that
> > case the natural type based on the current spec is its erasure, which is
> > not
> > necessarily AutoCloseable.
More information about the coin-dev