alex.blewitt at gmail.com
Wed Dec 16 01:47:10 PST 2009
On Dec 16, 2009, at 09:37, Mark Thornton wrote:
> Alex Blewitt wrote:
>> On Wed, Dec 16, 2009 at 9:06 AM, Peter Levart
>> <peter.levart at marand.si> wrote:
>>> For the "name" part, maybe alternative is specifying it directly
>>> in the lambda expression like this:
>>> #int(int, int) plus = #(int a, int b) a+b; // produces annonymous
>>> class name, sensitive to position in source
>> I don't see that the name is at all relevant, since the name is part
>> of the variable that it gets assigned to and not an intrinsic
>> of the lambda itself.
> The name of an anonymous class is something like ContainingClass$<i>
> where <i> is its index in the anonymous classes generated for that
> container. So declaring another anonymous class changes the name of
> all anonymous classes appearing later in the source.
It won't be generally safe to safe to use the name of the class
anyway, will it? ContainingClass may well not exist on the other end.
Serialization will need to deal with these specifically, rather than
using the classname as an identifer for what to deserialize. It may
mean that there is some special kind of class (say, GlobalLambda) to
which deserialized lambdas get attached to upon reserialization.
An SHA-1 hash of the bytecode to be used is at least as sufficient as
Git's mechanism for determining contents of files. So upon writing a
lambda, we write out GlobalLambda$sha1hash [bytecode], and on the
other end, deserialize the same.
More information about the lambda-dev