[Prev][Next][Index][Thread]
Re: Closures
-
To: info-dylan@ai.mit.edu
-
Subject: Re: Closures
-
From: bernhard@hummel.cs.waikato.ac.nz (Bernhard Pfahringer)
-
Date: Wed, 15 Aug 2001 01:15:01 -0400 (EDT)
-
Cache-Post-Path: clint2.its.waikato.ac.nz!unknown@hummel.cs.waikato.ac.nz
-
Organization: I need to put my ORGANIZATION here.
-
References: <200108141636.MAA07210@life.ai.mit.edu>
-
Sender: bernhard@cs.waikato.ac.nz
-
Xref: traf.lcs.mit.edu comp.lang.dylan:13598
In article <200108141636.MAA07210@life.ai.mit.edu>,
Jeff Dalton <jeff@aiai.ed.ac.uk> wrote:
>
>The problem with that answer is that inner classes were defined (or at
>least explained) by code rewriting, and "shared binding" assignment
>can be implemented with some additional, reasonably straightforward,
>rewriting - in such a way that the "extra" run-time performance
>penalty when when you don't actually assign to the variable is zero.
>(It's essentially just the rewriting you have for Python but doing it
>only for the variables that need it.)
>
>Moreover, they didn't invent some "weird" different semantics,
>just said the variables had to be "final".
>
>So I think there was probably a substantial "don't care" about it:
>supporting "shared binging" assignment wasn't seen as important.
>
Hi, forgive me if I am being dense here, but could somebody please
give me a (preferably short) Java code fragment, that exposes the
"shared binding" assignment problem?
cheers, Bernhard
--
---------------------------------------------------------------------
Bernhard Pfahringer, Dept. of Computer Science, University of Waikato
http://www.cs.waikato.ac.nz/~bernhard +64 7 838 4041
---------------------------------------------------------------------