Add polling

[Ketasaja]

• New option call_default.
• New EvCall:Polling variant.
• Explicit iteration exists because type inference for loop variables with generalized iteration isn't stable yet until the new solver releases.

[sasial-dev]

Thanks for this!
I started by reviewing general code stuff. I'll let @jackdotink review first and then I'll go through and test the output locally.

[Ketasaja]

Instead of adding a new event field I added EvCall::Polling.

I need to make the global option configure the default EvCall, update the docs, fix TypeScript polling, and add error handling for when there's no call specified.

[Ketasaja]

I think in a rewrite or in the future in general, Zap should report an error and exit immediately when one is encountered.

[sasial-dev]

The reason why we did that is for error recovery I think. It would make it much eaisier for stuff like building an LSP etc

[jackdotink]

if true is being used as a placeholder, then what happens to real true values? I recommend we use some "null" userdata to represent nil

[sasial-dev]

Or maybe we use a counter for events w/o data instead of an array - sorta like how it works already for queuing

[Ketasaja]

Or maybe we use a counter for events w/o data instead of an array - sorta like how it works already for queuing

Something needs to be returned to the loop or iteration will end, there's no player to return on the client.

[Ketasaja]

if true is being used as a placeholder, then what happens to real true values? I recommend we use some "null" userdata to represent nil

I don't see much benefit to this unless you assign a metatable that errors on everything, but you don't like metatables. I could make this change though.

for meaningless_value in event do
    if meaningless_value then
        -- Same behavior either way.
    end
end

[Ketasaja]

You'd also need to lie to the type system because newproxy(true) returns any, which would be worse than true.

[jackdotink]

we need to do something because if we use true then boolean? becomes impossible

[Ketasaja]

I changed the placeholder value to an explanatory string literal because I don't think a newproxy userdata adds any benefit. newproxy values are any type, which is worse than a singleton. A metatable that errors on everything might be useful, but Zap doesn't like metatables.

for meaningless_value in event do
    if meaningless_value then
        -- Same behavior whether `meaningless_value` is a `newproxy` userdata or not.
    end
end

I can change this if necessary.

[sasial-dev]

Does it matter that newproxy is typed as any? We can type it as never ourselves if we really want to.

[sasial-dev]

I'd also prefer we didn't use a string singleton.

[Ketasaja]

Does it matter that newproxy is typed as any? We can type it as never ourselves if we really want to.

never won't cause type errors. A string singleton will at least cause type errors in strict mode whenever it's used in a non-string or other string literal context, and would be obvious once inspected at runtime. If the userdata is passed around it won't be obvious what it is outside of networking code when debugging.

If you want the change to userdata with that said, I'll make it, but I think a string singleton is the least wrong option.

[sasial-dev]

*unknown, not never sorry

[sasial-dev]

As discussed with @jackdotink - I think this PR is overcomplicated and has a ton of merge conflicts. We'd still be open to a new implimentation, though!