Normalise string coersion in Java functions #1445
Labels
area-Core
This affects CC's core (the Lua runtime, APIs, computer internals).
area-Minecraft
This affects CC's Minecraft-specific content.
enhancement
An extension of a feature or a new feature.
Milestone
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 gettable: 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:
IArguments.getStringCoerced
method, which callsLuaValue.toString()
on the original value. This may require some extra thought to handletostring
does not obey__name
. Cobalt#69. We should probably have anOptional<T>
version of this too.@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.StringUtil.toString
to call this instead.The text was updated successfully, but these errors were encountered: