Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
/*
|
|
|
|
* This file is part of ComputerCraft - http://www.computercraft.info
|
2021-01-06 17:13:40 +00:00
|
|
|
* Copyright Daniel Ratcliffe, 2011-2021. Do not distribute without permission.
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
* Send enquiries to dratcliffe@gmail.com
|
|
|
|
*/
|
|
|
|
package dan200.computercraft.core.lua;
|
|
|
|
|
|
|
|
import dan200.computercraft.ComputerCraft;
|
|
|
|
import dan200.computercraft.api.lua.IArguments;
|
|
|
|
import dan200.computercraft.api.lua.ILuaContext;
|
|
|
|
import dan200.computercraft.api.lua.LuaException;
|
|
|
|
import dan200.computercraft.api.lua.MethodResult;
|
|
|
|
import dan200.computercraft.core.asm.LuaMethod;
|
|
|
|
import org.squiddev.cobalt.LuaError;
|
|
|
|
import org.squiddev.cobalt.LuaState;
|
|
|
|
import org.squiddev.cobalt.Varargs;
|
|
|
|
import org.squiddev.cobalt.function.VarArgFunction;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* An "optimised" version of {@link ResultInterpreterFunction} which is guaranteed to never yield.
|
|
|
|
*
|
|
|
|
* As we never yield, we do not need to push a function to the stack, which removes a small amount of overhead.
|
|
|
|
*/
|
|
|
|
class BasicFunction extends VarArgFunction
|
|
|
|
{
|
|
|
|
private final CobaltLuaMachine machine;
|
|
|
|
private final LuaMethod method;
|
|
|
|
private final Object instance;
|
|
|
|
private final ILuaContext context;
|
|
|
|
private final String name;
|
|
|
|
|
|
|
|
BasicFunction( CobaltLuaMachine machine, LuaMethod method, Object instance, ILuaContext context, String name )
|
|
|
|
{
|
|
|
|
this.machine = machine;
|
|
|
|
this.method = method;
|
|
|
|
this.instance = instance;
|
|
|
|
this.context = context;
|
|
|
|
this.name = name;
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public Varargs invoke( LuaState luaState, Varargs args ) throws LuaError
|
|
|
|
{
|
|
|
|
IArguments arguments = CobaltLuaMachine.toArguments( args );
|
|
|
|
MethodResult results;
|
|
|
|
try
|
|
|
|
{
|
|
|
|
results = method.apply( instance, context, arguments );
|
|
|
|
}
|
|
|
|
catch( LuaException e )
|
|
|
|
{
|
|
|
|
throw wrap( e );
|
|
|
|
}
|
|
|
|
catch( Throwable t )
|
|
|
|
{
|
2020-05-15 21:44:46 +00:00
|
|
|
if( ComputerCraft.logComputerErrors )
|
Replace getMethodNames/callMethod with annotations (#447)
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
|
|
|
{
|
|
|
|
ComputerCraft.log.error( "Error calling " + name + " on " + instance, t );
|
|
|
|
}
|
|
|
|
throw new LuaError( "Java Exception Thrown: " + t, 0 );
|
|
|
|
}
|
|
|
|
|
|
|
|
if( results.getCallback() != null )
|
|
|
|
{
|
|
|
|
throw new IllegalStateException( "Cannot have a yielding non-yielding function" );
|
|
|
|
}
|
|
|
|
return machine.toValues( results.getResult() );
|
|
|
|
}
|
|
|
|
|
|
|
|
public static LuaError wrap( LuaException exception )
|
|
|
|
{
|
|
|
|
return exception.hasLevel() ? new LuaError( exception.getMessage() ) : new LuaError( exception.getMessage(), exception.getLevel() );
|
|
|
|
}
|
|
|
|
}
|