Re: Roberto book, persistance, data structures

["Joshua Jensen" <jjensen@...>]

I've switched formats for ALL of the data used in my applications to a Lua
compatible form (where practical of course... lots of binary data =
impractical).  This lets anyone who knows Lua the least little bit modify
the data and write it back out.  Scripts can be written to batch process
data or even to write it out in a custom binary format, if needed.

The point is, I find it impractical to write custom parsers for the types of
data Lua handles best.  The power and control given to the user through the
scripting capabilities are unmatched.  The concept of "macros" (as I've
described to some of the people who use Lua to create large amounts of data)
can be implemented to speed data manipulation:

function MakeBoat(color)
    local table =
    {
        Data1 = "blah",
        Data2 = 5,
        Color = color,
    }
    return table
end

Boats =
{
    MakeBoat("red"),
    MakeBoat("blue"),
    MakeBoat("green"),
    MakeBoat("yellow"),
}

4 lines instead of 20 lines to describe the boats, and a lot easier to
maintain.  The best part is, rather than taking the runtime hit for
generation of the boats, the file can be loaded into a Lua state and dumped
back out (say, through my Lua wrapper's Script::SaveText() function...
although it doesn't handle cyclic data)... find it in the Misc. Code section
of http://workspacewhiz.com/.

Anyway, I'd recommend that anyone use Lua FIRST for their data and
scripting, and if needed, custom solutions can be built.  I find the need
for custom solutions to be few and far between.

Just my take,
Josh


----- Original Message -----
From: "Nicolas Devillard" <ndevilla@eso.org>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Wednesday, July 18, 2001 8:53 AM
Subject: Re: Roberto book, persistance, data structures


>
> On Wed, 18 Jul 2001, Philippe Lhoste wrote:
> [...]
> > The .ini format is fine, except it doesn't support multi-users (or you
> > must handle these by hand), and it is not hierarchical.
>
> The ini file format can be made hierarchical by reserving a character as a
> separator in the section names. Example: with '/':
>
> [Section/Subsection1]
> [Section/Subsection2]
> ...
>
> Use any character you want as long as it is not used in a section label,
> and you have your hierarchical ini file. Not the best but you can find
> parsers for ini file all over the place so you do not have to reinvent the
> wheel. All depends on how hierarchical you need your file to be. XML might
> also be a choice there.
>
> As to making the ini file aware of different users, nothing prevents you
> from using a naming scheme to do that, something like appli-user1.ini,
> appli-user2.ini, etc.
>
> Many, many solutions for config files out there. Have a look into
> freshmeat for starters :-)
>
> Cheers
> --
> Nicolas
>
>
>