Re: pseudo self modifying code?

[Chris Babcock <cbabcock@...>]

On Thu, Feb 3, 2011 at 7:15 AM, Patrick Mc(avery
<spell_gooder_now@spellingbeewinnars.org> wrote:
> On 02/03/2011 06:44 AM, Gaspard Bucher wrote:
>>
>> Have you thought about LuaSQLite ? With some simple wrappers in Lua
>> (metatables), you can use table syntax to read and update your data:
>>
>> device = db:device('device name')
>> -- read db
>> print(device.name <http://device.name>)
>> -- update db
>> device.name <http://device.name> = xxx
>>
>> If you really need to be able to hand edit the result, YAML is a very
>> good choice. JSON (or Lua tables) tend to become unreadable.
>>
>> Gaspard
>
> Hi Gaspard
>
> Thanks very much for your post and thanks to Axel, Peter and Jerome for
> theirs as well.
>
> DBs are really powerful but are just not my style. I had heard of YAML but
> did really know what it was, I think this is perfect for me, there is even a
> Lua binding.

YAML is a superset of JSON. ;)

Lua has safe quoting built in (See PIL 12.1.) so there's no security
advantage to using YAML over raw Lua for data. The advantage of using
YAML, JSON, XML or some other non-executable serialization format
would be portability. The price for that portability is performance,
which probably isn't too significant but may be depending on your
hardware, your application and the serialization format/library.

Storing serialization files in a directory is going to be faster than
retrieving them from a database for up to 10-15k records on an
ext-based file system. You can extend the usability of file system
storage for serialization by using a hashed file system or by hashing
your directory structure.

If it's only the properties of your state (object or environment) that
need to be persisted - because the methods don't change - then a
serialization function like the ones in PiL and the LuaUsers wiki will
be sufficient for packing and loadfile() sufficient for unpacking.
Templating doesn't become useful until you're trying to think of a way
to serialize functions - for example, including variant rules in an
object describing the state of a game.

Chris
--
51st century guy