lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> 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 =)

> 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?

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.