themodmaker / modmaker.lua Goto Github PK

Currently the CodeCompiler can save the code to an assembly file, but the only way to load it is to use dynamic loading within Lua code using modules. It would be better to add a method LoadCompiled to the Lua type to load the compiled code.

There are almost no unit tests. Need to add a bunch more of them so I can be more sure this works as expected.

Some of the new features available in C# 6 will help a lot. Mainly the nameof operator which will greatly help with all the reflection and getting members by name.

Currently, the unit tests are written using the Visual Studio test framework. Unfortunately, this means that the tests cannot run under mono on Linux. We should change the unit tests to use a cross-platform unit tests framework so it can be run on mono.

Although having plain expressions is not valid Lua code, it is still useful to parse a single expression from a string. For example, the parser can be used by itself to parse expressions found in a file or given to a program. This will not be used internally.

It may also want to add the ability to compile the expression by itself to get the value.

This attribute will indicate that extra arguments can be passed to this method and they are ignored. Otherwise, any extra arguments are treated as an overload error. In terms of overload resolution, it will treat this as having an invisible params array of type object. So the following will be ambiguous:

void Foobar(int i, params object[] extra);

[IgnoreExtraArguments]
void Foobar(int i);

The code is littered with usages of string literals. These should be consolidated into a few places and the error strings should be moved to resource files.

Because of the dynamic invocation of many methods, there are a number of cases when an exception will be wrapped in a TargetInvocationException. It would be better to unwrap it and throw the original exception.

It is possible to use internals to throw the exception with preserving the stack trace, but it not ideal. But when we upgrade to .Net 4.5 we can use ExceptionDispatchInfo to do it correctly.

This mirror of the CodePlex code is not up to date. Need to update to the latest version.

Putting parentheses around a function call should collapse the return values into one. Namely (foo()) should result in one return value.

function foo()
  return 1, 2
end

a, b = (foo())
assert(b == nil)

Somehow there were git merge conflict markers pushed to this repo, they need to be fixed.

If a method defined on a class is called from within Lua, it is boxed, converted, then converted back and unboxed. It would be better to detect that the method is defined in Lua and call it directly to avoid the extra boxing and conversions.

Example:

interface ITest {
  int Do();
}

class Test : ITest

function Test::Do()
  return 12
end

local obj = Test()
local x = obj:Do()

In this example, the call to Do will first return the 12 as a double in a multi-value. Then it is converted to an integer in a wrapper function for the C# interface. Then it is boxed and converted back to a double to store in the variable x.

Recently, operator handling was removed from userdata objects. It should be added back. Any operator use on a userdata value should be forwarded to the respective C# operator method, if present.

https://github.com/TheModMaker/ModMaker.Lua/blob/master/ModMaker.Lua/Runtime/LuaValues/LuaUserData.cs#L90-L125

Currently, you can only add fields to a Lua defined type by defining it on the constructor. If you attempt to access a nonexistent field after construction, it will throw an exception because the field is not found. For C# defined types, this makes sense since the field doesn't exist. But it would be beneficial to be able to add fields dynamically to a Lua defined types.

Note that this will NOT change the C# exposed type. This will only affect field access within Lua. To have a field visible to C# code, it MUST be defined on the constructor so it appears in the generated type signature.

class Type

function Type:__ctor()
  self.newField = 123
end

-- Currently you have to define the field using a default or a type.
-- Type.newField = int

local inst = Type()
assert(inst.newField == 123)

It may be useful to define the global environment as read-only. Such that it is not possible to create/modify any global variables. This will not effect locals.

-- Not allowed:
my_global = 12
-- Locals ok
local my_local = 12
-- Calling functions is allowed
foobar()

Currently the "demo" simply runs a single Lua file and stops. This provides a good starting point for actual applications, but really belongs in a tutorial, not in its own project. Instead, we should have a REPL (read, eval, print, loop) program that most Lua programs use. This will involve allowing expressions to be used by themselves (see #6).

With the new .Net Core, we can run the library on non-Windows platforms without requiring mono. We should upgrade the library to use the new system and to allow building on Linux/Mac.

This will involve removing the portable library and squashing ModMaker.Lua.Net.dll into ModMaker.Lua.dll. Apparently no one wants to have portable library support (see discussion).

There are two places where dynamic assemblies are used. One is for the .NET CodeCompiler for generating Delegate types for Lua methods. This always uses the same dynamic assembly. Second, there is a dynamic assembly in each Lua class. Neither of these can be saved.

Although it is unlikely these would be useful to outside users, it would make debugging internally easier if it was in one place that could be saved to view in a disassembler.

The documentation states that this is based on version 5.2. There is now a version 5.3. Need to investigate what changes are needed to be compliant with the new spec and update the documentation.

Changes since 5.2

• Native integer support
  • Bitwise operators
  • math.tointeger, math.ult, math.maxinteger, and math.mininteger
  • math.type
• utf8 library
• string.pack, string.unpack, and string.packsize
• table.move
• Update metamethods