RE: Lua as a configuration file

[Thatcher Ulrich <tu@...>]

On Fri, 27 Sep 2002, Pyrogon Public wrote:

> > Pedantic note: Lua definitely has types, and not everything
> > is a table.  Numbers, strings, bool, nil, userdata are all
> > different types. Enough pedantry, since it doesn't solve your
> > problem...
>
> You know what I meant, you weenie =)

Guilty :) But what you said was pretty broad, I couldn't resist...

> > I think one common idiom is constructor syntax, using a table
> > argument, like:
> >
> > a = window{
> > 	x = 100,
> > 	y = 10
> > }
> > Lua turns that into a call of the "window" function, passing
> > the {...} as a table argument to the function.  So you could
> > just return the new object from that function.  It can be
> > defined in Lua or in the host language; in Lua it might look like:
> >
> > function window(attributes)
> > -- return a new window with the given attributes
> > 	return appCreateWindow(
> > 		attributes.x or 640,
> > 		attributes.y or 480)
> > end
>
> The only real difference between the above and my example is that there
> is now an identifier to go with each window, right?  In other words, if
> the script itself doesn't need to reference each window (because it's
> being used for configuration, not really for scripting), then
>
> appCreateWindow( 100, 10 )
>
> would work just as well I take it, a la my example?

Yeah, basically I just regurgitated your exaple.  I wasn't sure if
you'd seen that table arg syntax before.

> I guess my question really comes down to this: if the app needs to
> create arbitrary entities based on a configuration file (and thus
> doesn't know the names of the entities to query), is it better to just
> iterate over all tables and inspect them and act appropriately, or is it
> more common/sane to have the script explicitly create entities by
> calling into the app?  I don't even need to keep identifiers around,
> it's purely a way to make the app data driven.

Personally, I think it's nicer and more flexible to have the script
create the entities.  I think the constructor concept is pretty easy
for most content people to pick up, and you may find it comes in handy
for doing stuff at run-time (i.e. not just at startup).  But I don't
know what's more common.  Surely both will work.

-Thatcher