diff options
| -rw-r--r-- | lua_as_human_readable_serialization_format.html | 26 |
1 files 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}, } </pre> -<p>This makes use of how <a href="https://www.lua.org/manual/5.4/manual.html#6.3">modules</a> and importing them works. -In short, module script is interpreted and value of the final <code>return</code> 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 +<p>This makes use of how <a href="https://www.lua.org/manual/5.4/manual.html#6.3">modules</a> are imported. In short, +module script is interpreted and value of the final <code>return</code> 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. <p>In the example above we are not really sure what kind of thing we are dealing with. To stay consistent we could add a <code>type = "slime",</code> 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}, } </pre> -<p>It now looks like some generic markup language. But the module loading mechanism will no longer work for us. Instead -reader needs to use <a href="https://www.lua.org/manual/5.4/manual.html#pdf-load">load</a>. It conveniently has an -option to specify execution environment. Additionally, a mechanism for tracking top-level statements in one way or -another is needed. -<p>This approach is somewhat similar to what <a href="https://premake.github.io/">Premake</a> does. Surprisingly, this -is also pretty close to regular register-event-callback approach for plugin systems (e.g., in -<a href="https://github.com/martanne/vis">vis</a>). 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 +<p>It now looks like generic markup language but the module loading mechanism will no longer work for us. Instead +reader needs to <a href="https://www.lua.org/manual/5.4/manual.html#pdf-load">load</a> 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. +<p>This approach is somewhat similar to what <a href="https://premake.github.io/">Premake</a> does. And surprisingly, +this is also pretty close to a regular register-event-callback approach that some plugin systems use (e.g., +<a href="https://github.com/martanne/vis">vis</a>). 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). <p>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 |