Re: Pluto: heavy-duty persistence for Lua

[benjamin sunshine-hill <bsunshin@...>]

My current thought is to use the "third" option: Have __persist be a function which returns a function and an arbitrary number of arguments. Then, during unpersistence, those arguments are passed into those functions. That makes the easy-to-hit closure bug less likely:

mt.__persist = function(tbl) do
 return function(x,y,z) do
    return {x=x, y=y, z=z}
 end, tbl.x,tbl.y,tbl.z
end

Thoughts?

Ben

----- Original Message -----
From: Mark Hamburg <mhamburg@adobe.com>
Date: Friday, June 4, 2004 11:53 am
Subject: Re: Pluto: heavy-duty persistence for Lua

> on 6/4/04 8:41 AM, Virgil Smith at Virgil@Nomadics.com wrote:
> 
> > In fact the only real "complexity"/"gotcha" here is that the following
> > version of "Returning a closure" is VERY WRONG
> > 
> > -- Returning a closure (INCORRECTLY)
> > -- This will force tbl itself to be persisted
> > -- in the stream
> > mt.__persist = function(tbl) do
> >  return function() do
> >     return {x=tbl.x, y=tbl.y, z=tbl.z}
> >  end
> > end
> 
> That's also potentially an easy mistake to make. Also, relying on generating
> lots of closures or auxiliary tables creates just to strip stuff out creates
> a lot of extra memory allocation traffic which hurts efficiency. Now, if one
> went with tables rather than closures or in addition to closures as the
> results of the __persist metamethod and passed the method an empty table
> that the persistence mechanism would clear and reuse later, you might be
> able to work around that memory overhead issue.
> 
> Mark
> 
> P.S. These sort of cases make a table.clear function that resets a table
> back to the empty state attractive.
> 
>