Byondapi: Access to the hascall builtin.

ID:2913948
 
Feb 22, 3:22 pm
Applies to:byondapi
Status: Open
Issue hasn't been assigned a status value.
I believe that hascall is a useful builtin to have access to in byondapi.

In my particular use case (integrating an external scripting language), indexing a ref value that has procs can result in returning a var or a proc. I am able to perform several checks that determine whether an index corresponds to a given var, but I cannot determine if an index is a valid proc. As such, I have to assume that any index that is not a var is a proc, and if it really is a proc, then all's well and good.

This workaround could cause issues for end users, who may index a ref value with a member it doesn't have, while getting back a function that attempts to call a proc that doesn't exist.

Access to hascall in byondapi would solve this issue, allowing me to either cause the external script to error or return null if an index does not correspond to a var or proc member.
Mar 15, 11:46 pm (Edited on Mar 16, 1:34 pm)
An update regarding the use case mentioned in the above post.

The check I use to determine if an index corresponds to a valid var identifier takes 15ms, which is absolutely unacceptable for the purpose it is meant for. Having access to hascall would let me simply check if an index is a proc, and if it isn't, attempt to read it as an var. This would be orders of magnitude faster.

The library that preceded the one I am developing uses a syntax that doesn't require the absurdly slow check I described, but implementing it would require significantly refactoring the library I have developed so far.

Edit: I realized I can work around this by defining a global proc that wraps hascall, and calling that, but native access to hascall would likely be substantially more performant.