View Issue Details

IDProjectCategoryView StatusLast Update
0000594LDMudEfunspublic2021-05-05 19:02
ReporterGnomi Assigned To 
PrioritylowSeverityminorReproducibilityalways
Status newResolutionopen 
Platformi686OSDebian GNU/LinuxOS Version4.0
Summary0000594: save_value doesn't need to save inline closures
Descriptionsave_value takes its time to save inline closures, there is code in it only for them (e.g. saving context variables). But restore_value can't restore them.

The main reason for this is, that the lfun of the inline closure is private and so it is not included in the function name lookup table (the table contains only visible function names) and therefore can't be found by restore_value. symbol_function() has the same limitation for the same reason.

I think the reasons are conceptually sound. Inline closures are invisible, almost volatile functions (just like lambdas) and therefore should not be saved by save_value/object.
TagsNo tags attached.
External Data (URL)

Activities

zesstra

2009-01-15 13:57

administrator   ~0000892

I would not describe them as 'volatile' (then other functions are IMHO volatile as well), but as they are private and the savefile might be restored to a different object, I guess they should not be restored. And then I also agree, that we should not save them.

zesstra

2021-05-05 19:01

administrator   ~0002629

Last edited: 2021-05-05 19:02

One should add: if restore_object could restore closures to private functions, any inheritee could create closures to private functions they would otherwise not see, by creating a specially crafted savefile. That seems to me the most important conceptional issue.

Issue History

Date Modified Username Field Change
2009-01-14 16:49 Gnomi New Issue
2009-01-15 13:57 zesstra Note Added: 0000892
2021-05-05 19:01 zesstra Note Added: 0002629
2021-05-05 19:02 zesstra Note Edited: 0002629