CC: Tweaked

CC: Tweaked

57M Downloads

Normalise string coersion in Java functions

SquidDev opened this issue ยท 0 comments

commented

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 calls LuaValue.toString() on the original value. This may require some extra thought to handle cc-tweaked/Cobalt#69. We should probably have an Optional<T> version of this too.
  • Add some way to request these coerced values from @LuaFunctions. Maybe an annotation on the argument, or a Coerced<T> wrapper type. Not sure - there's an argument we'd want to extend this to Number-like types in the future too.
  • Convert the existing calls to StringUtil.toString to call this instead.