[DGD] lambda operator re-re-visited?

Raymond Jennings shentino at gmail.com
Tue Jan 3 19:39:42 CET 2017


I agree with felix on this opinion.

More to the point, however, I also want to point out what I mentioned in
the chatroom, that there is an inherent conflict between in-place
recompilation and anonymous functions.

I would STRONGLY suggest that you bear it in mind.  My advice is to simply
invalidate lambdas attached to a recompiled object (especially if they
happen to be attached to an object-scoped variable that ceases to exist).
LPC layering on top could always ban recompiles by masking compile_object,
and how to handle recompiles of programs with lambdas is a policy issue
that rightly belongs in a higher layer.

On Tue, Jan 3, 2017 at 10:18 AM, Felix A. Croes <felix at dworkin.nl> wrote:

> Carter Cheng <cartercheng at gmail.com> wrote:
>
> > My thought on this is to not recompile L when A is recompiled since
> lambda
> > operators are runtime operators and should have the illusion of creating
> > the function on the spot.
>
> Scenario: you're patching a low-level inherited object to fix a security
> bug.  Unrecompiled anonymous functions will inherit old code, and thus be
> a security problem.
>
> Scenario: you're patching a low-level object to reflect an interface
> change.
> Unrecompiled anonymous functions will attempt to use the old interface, and
> will no longer work.
>
> Giving up system-wide full recompilation of all objects and functions to
> provide the illusion of creating functions on the spot seems like a poor
> trade-off.
>
> Regards,
> Felix Croes
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>



More information about the DGD mailing list