From bd159f4c18ec8b193e797aedfa271550e4a98177 Mon Sep 17 00:00:00 2001 From: Aki Date: Wed, 13 Nov 2024 15:18:09 +0100 Subject: Reworded parts on premake of Lua-Serialization article --- lua_as_human_readable_serialization_format.html | 26 ++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/lua_as_human_readable_serialization_format.html b/lua_as_human_readable_serialization_format.html index 1802aa1..75e6117 100644 --- a/lua_as_human_readable_serialization_format.html +++ b/lua_as_human_readable_serialization_format.html @@ -33,10 +33,10 @@ return { position = {x=0, y=0}, } -

This makes use of how modules and importing them works. -In short, module script is interpreted and value of the final return is used as the value for the "module". -In this case the script is a lone return-statement with no logic involved. This somewhat declarative-like style is -purely conventional. More commonly the returned value is a table of functions, exactly what we would consider a "normal +

This makes use of how modules are imported. In short, +module script is interpreted and value of the final return is used as the value for the "module". In this +case the script is a lone return-statement with no logic involved. This somewhat declarative-like style is purely +conventional. More commonly the returned value is a table of functions, exactly what we would consider a "normal module", or a class.

In the example above we are not really sure what kind of thing we are dealing with. To stay consistent we could add a type = "slime", to the table. Now reader would know what they are dealing with. Of course, scheme would @@ -63,15 +63,15 @@ Slime { position = Vec2{x=0, y=0}, } -

It now looks like some generic markup language. But the module loading mechanism will no longer work for us. Instead -reader needs to use load. It conveniently has an -option to specify execution environment. Additionally, a mechanism for tracking top-level statements in one way or -another is needed. -

This approach is somewhat similar to what Premake does. Surprisingly, this -is also pretty close to regular register-event-callback approach for plugin systems (e.g., in -vis). How so? The "tracking top-level statements" will result in a -side-effect in some global or loader state. In callback approach, it's the event dispatcher or otherwise plugin system -state that fulfils similar role. Additionally, API is usually exposed through environment (and not e.g., user function +

It now looks like generic markup language but the module loading mechanism will no longer work for us. Instead +reader needs to load it and execute. Functions +handling data types here are expected to cause side-effects in order to record the entries. This may be coupled with a +way of detecting top-level statements. Load conveniently has an option to specify execution environment. +

This approach is somewhat similar to what Premake does. And surprisingly, +this is also pretty close to a regular register-event-callback approach that some plugin systems use (e.g., +vis). How so? Here, point is to modify loader state as side-effect. In +callback approach, when plugin is loading it has access to register itself for certain events, modifying the plugin or +event system's state. Additionally, API is usually exposed through an environment (and not e.g., user function argument and plugin returned as module never able to directly interact with the API).

For my standards definitions I settled for the last style. It allows for multiple items without indention and I liked the idea at the time. It allowed me to play around and neatly layer parser, environment, and model. Final definitions -- cgit v1.1