Closed ribrdb closed 5 months ago
I like the syntax using function calls. Maybe we should generate functions for each individual component, instead of having overrides for a "component" function?
I'm not sure about generating a function for each component. This would be quite a lot of function names that would become unavailable to users for names as e.g. subroutines. I'd prefer to keep the amount of declarations in the global scope to a minimum.
Though we could also put them in an object... Something like:
internal: [
component.signalReader([from("reg1"), to("goto")])
]
I'm also not sure whether we should always use an object argument, or positional arguments. The big benefit of an object argument is future-proofing, since it allows us to add additional optional or required properties down the line while keeping source backwards-compatability.
But as far as I can tell the game only allows us to configure the registers per component, with the behavior controller being special and also referencing a behavior. I don't think this is likely to change, so we can do:
signalReader(registers: Array<RegisterValue>)
Instead of:
signalReader(args: {
reg: Array<RegisterValue>
});
We could even go a step further and parse components.lua
and extract information about read only registers, and go for:
type ToRegisterLink = { to: string };
type FromRegisterLink = { from: string };
type RegisterLink = ToRegisterLink | FromRegisterLink;
type RegisterValue = RegisterLink | LiteralValue;
signalReader(
reg?: [
RegisterValue?,
// parsed read_only to ToRegisterLink
ToRegisterLink?
]
): InternalComponent;
I'm not sure about generating a function for each component. This would be quite a lot of function names that would become unavailable to users for names as e.g. subroutines. I'd prefer to keep the amount of declarations in the global scope to a minimum.
Though we could also put them in an object... Something like:
internal: [ component.signalReader([from("reg1"), to("goto")]) ]
I like that. Mainly I was thinking that with a function we can customize the name to be more user-friendly than the "c_foo" strings.
Figured out in https://github.com/ribrdb/desynced-tools/pull/54 :)
What do you think about syntax like this?
Alternatively, instead of utilizing the magic functions, it could be a pure JSON document. So for example instead of
We could also do
This would be a bit more verbose. Both could also be supported at the same time, with the magic functions acting as helpers.
Either way, this would require us to parse the visuals.lua & frames.lua to extract information such as:
so we can validate/map the components to the correct socket index.