View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000594 | LDMud | Efuns | public | 2009-01-14 17:49 | 2021-05-05 21:02 |
| Reporter | Gnomi | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | i686 | OS | Debian GNU/Linux | OS Version | 4.0 |
| Summary | 0000594: save_value doesn't need to save inline closures | ||||
| Description | save_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. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
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. |
|
|
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. |
