Normalise string coersion in Java functions
SquidDev opened this issue ยท 0 comments
There are several functions (term.write
, writing to a file handle or websocket), which accept any Lua value and convert it to a string. However, as this conversion is done in Java (after conversion from Lua values), the behaviour can be pretty confusing.
For instance, using term.write({})
on a normal computer will print {}
(which uses the native terminal), while on an advanced computer (which uses multishell), you get table: 0xfffff
.
We should probably standardise on the Lua representation of these strings. This is technically a breaking change, but I'm going to handwave it away by arguing that the current behaviour is buggy.
I think we probably need to make the following changes:
- Add a new
IArguments.getStringCoerced
method, which callsLuaValue.toString()
on the original value. This may require some extra thought to handle cc-tweaked/Cobalt#69. We should probably have anOptional<T>
version of this too. - Add some way to request these coerced values from
@LuaFunction
s. Maybe an annotation on the argument, or aCoerced<T>
wrapper type. Not sure - there's an argument we'd want to extend this toNumber
-like types in the future too. - Convert the existing calls to
StringUtil.toString
to call this instead.