node.getChild(string) vs DB.getChild(node, string)

[seansps]

You're still assigning this library of functions to "databasenode" as a variable. It's all the same thing you're hashing over.

Regards,
JPG

Right, this is just for a POC, as it's just a basic terminal app.

The code that returns userdata objects for `DatabaseNode`s (like window.getDatabaseNode()) would need to be modified to instantiate a reference to this new class.

[MeAndUnique]

On the string.fn(var, ...) vs. var:fn(...) part of the discussion; this approach with databasenode objects would not smooth migration any more than migrating to DB. That is because all the var.fn(...) calls with databasenode vars would need to be converted to either databasenode.fn(var, ...) or var:fn(...). Not really much savings in coding effort in that approach.

The current recommended change is DB.fn(var, ...). How is that different than the former conversion above?

Also, I think that the level of work that is being assumed with this change is higher than it is, I was able to convert about 20 rulesets in a couple days, including Core which is larger than most of the other rulesets.

Regards,
JPG

Strictly speaking the syntax I was hypothesizing would be converting the existing "node.function(....)" to "node:function(...)" where database nodes are treated similarly to string under the hood and mapped to DB API calls.

[MeAndUnique]

Actually, there is not a way to maintain a dot notation in Lua without embedding the API into each object. The way that Lua works is that the dot notation is a Lua table lookup, so that name = fn entry must exist in the object in order for var.fn(...) to work.

As mentioned above, adding a "databasenode" "library" to support databasenode.fn(var, ...) or var:fn(...), is not that different than DB.fn(var, ...). The example you displayed above just creates a "databasenode library".

Regards,
JPG

The cost in performance isn't in the act of being a table, it is in the act of creating a table. If the database node tables are created once and reused, then injecting a couple dozen function references once at instantiation (can even be done lazily) is genuinely negligible (massively less than 1%) in a system that uses ZIP archives as databases. Especially when considering that the FGU application itself already has to load some form of object for each node anyway to parse it from the underlying XML, which means the Lua userdata mechanism for mapping the underlying data could point directly to the C# objects resulting in script-side node interactions having virtually zero overhead of any sort.

[MeAndUnique]

Right, this is just for a POC, as it's just a basic terminal app.

The code that returns userdata objects for `DatabaseNode`s (like window.getDatabaseNode()) would need to be modified to instantiate a reference to this new class.

The omission of the salient detail of plugging into existing APIs is I think the crux of the contention here, as the example of registering a global databasenode object to the Lua context is in direct contradiction to the desired result.

[seansps]

The omission of the salient detail of plugging into existing APIs is I think the crux of the contention here, as the example of registering a global databasenode object to the Lua context is in direct contradiction to the desired result.

I am not sure I understand what you're saying here.

Basically, any time a databasenode is returned (a userdata object) by a call to a control or some other userdata object, the underlying C# application would instantiate a new `UserData` class and return that. Each class does not have a whole XML library instantiated/loaded in it (as I understand the current problem is) because it points to a reference managed by a Singleton, of which the application would only instantiate one of.

[Moon Wizard]

But all the functions have to be added to every databasenode object, or you can't call it like this [var.fn(...)]. Adding an additional "databasenode" context in the global space does not address that at all.

Regards,
JPG

[seansps]

But all the functions have to be added to every databasenode object, or you can't call it like this [var.fn(...)]. Adding an additional "databasenode" context in the global space does not address that at all.

Regards,
JPG

I am sure I am missing a lot of context (since I don't have the sourcecode) but wouldn't the every databasenode object have all the functions, if instantiated using the example code I provided? This wouldn't be a lot of overhead, because the class itself only has a reference to an XML library, and doesn't create the memory for the library itself.

[Moon Wizard]

As you say, I think there is context that you are missing. While I'm sure there will be more investigation into this part of the code when I get there, I think you are missing some key information in the way that Lua works in the interaction. A global object/script is very different than a custom data type with custom APIs.

For databasenodes to be called like they do know, you have to define every fn_name -> fn definition for every object in order to even allow that syntax to work, and then you have to make it contextual so that you know which object the function should be applied to (currently FG applies the fn_name -> object specific fn instance).

Regards,
JPG

[seansps]

As you say, I think there is context that you are missing. While I'm sure there will be more investigation into this part of the code when I get there, I think you are missing some key information in the way that Lua works in the interaction. A global object/script is very different than a custom data type with custom APIs.

For databasenodes to be called like they do know, you have to define every fn_name -> fn definition for every object in order to even allow that syntax to work, and then you have to make it contextual so that you know which object the function should be applied to (currently FG applies the fn_name -> object specific fn instance).

Regards,
JPG

Ahh okay, interesting. Thanks for the additional context. Sounds like quite the challenge in terms of tech debt. Hopefully a good compromise can be found!

[Moon Wizard]

Unfortunately, the tech debt was acquired before my involvement with FG, and part of the original API design in FG v2. I would like to move all custom data types to a model like the databasenode -> DB migration I'm proposing and working on.

While I know that there are savings to be add in terms of computing effort/speed with the change, the big question is still what the magnitude of the changes are. I'm hoping for a large change that will make everyone excited; but as MeAndUnique mentioned, I need to test and figure out if the gains rise above the level of a margin of error in the processing times.

Regards,
JPG