Method Overloading

[pupnewfster]

I am working on a system for Mekanism to allow me to more easily define methods in am abstracted method to allow me to easily support both ComputerCraft and OpenComputers (if it ever updates). While working on adding in some extra validation on our end about method collisions and "dynamically" fixing them by just pretending they have a different name than they actually do; for example: test -> test1 if there is already a method called test defined. I realized before I go too in depth into creating a fallback to gracefully handle all this stuff it would make sense to ask how well does ComputerCraft handle method overloading. From brief googling I believe these are Lua's restrictions to method overloading; this won't work:
test(int x)
test(String y)
as there is no type of the parameters so it doesn't know which one to call, whereas this will work:
test(int x)
test(int x, String y)
as the number of parameters are different. Is this the same for what restrictions ComputerCraft has or does it have extra restrictions based on how it looks up what method is being called from a peripheral? Also if how ComputerCraft wraps things also happens to remove the restriction that it seems Lua has due to how ComputerCraft wraps things that would be good to know as well.

[SquidDev]

I am working on a system for Mekanism to allow me to more easily define methods in am abstracted method to allow me to easily support both ComputerCraft and OpenComputers (if it ever updates).

Personal opinion incoming, but IMO the easiest solution here is to not go building your own abstraction layer right now, and just use @LuaFunction. There's no obvious timeline for when OC is going to update (the's a Fabric port in progress, but not much use to you :p), and until then you're just creating work for yourself.

Anyway, onto the actual question:

---

Lua doesn't really have a notion of methods or method overloading. As far as its concerned, test is a single function and, like all functions, it just accepts a list of values.

ComputerCraft is the same - fundamentally all functions just accept a list of IArguments and return a MethodResult. The whole @LuaFunction system isn't handling any overloading, it's just argument validation. You can write test(int x, Optional<String> y), but not both test(int x) and test(int x, String y) (as only one will be chosen).

In the cases where we do need to do "overloading", we just fallback to the IArguments path and roll our own type-checking code:

https://github.com/SquidDev-CC/CC-Tweaked/blob/1f70ed69854de12356681f4036458894a5848c0d/src/main/java/dan200/computercraft/core/apis/handles/BinaryWritableHandle.java#L66-L82

TLDR: No methods, no overloading. Just roll your own!

[pupnewfster]

Personal opinion incoming, but IMO the easiest solution here is to not go building your own abstraction layer right now, and just use @LuaFunction. There's no obvious timeline for when OC is going to update (the's a Fabric port in progress, but not much use to you :p), and until then you're just creating work for yourself.

This still doesn't get around the restrictions of needing the method to be public final or for that matter requiring a method to exist in the first place and having all the methods in one class instead of our multiblock ports being able to just proxy into methods defined in the multiblock.

as only one will be chosen

Thanks this answers my question.

[SquidDev]

need to be public final

The public is obviously unavoidable, the final less so. Just Java doesn't inherit annotations, so this seemed the safest way to enforce things.

requiring a method to exist in the first place and having all the methods in one class instead of our multiblock ports being able to just proxy into methods defined in the multiblock.

I'm not familiar enough with Mekanism to really know what you mean by the this point. I suspect the whole "generic peripheral" subsystem might have made things a little more palatable for you, but burnout means that's unlikely to ever get into a useable state :D:.

[pupnewfster]

The public is obviously unavoidable, the final less so. Just Java doesn't inherit annotations, so this seemed the safest way to enforce things.

Yes I understand from a complexity standpoint and based on how CC implements this based on the ASM generation stuff it does it makes sense. The system I wrote for Mekanism allows me to generate "methods" that act as getters and/or setters for fields (public, protected, or private), and also add support for methods (public, protected, or private), and even in theory "rename" said methods so if I end up annotating a method I am overriding from vanilla then it doesn't turn back into a srg name for what users are forced to call. In regards to Java not inheriting annotations that is fine for my case as well because after we collect them all, we go to supers to grab any references supers may have so that we don't miss any annotations, and given we do it based on method handles then it should support any methods that override it as well.

I'm not familiar enough with Mekanism to really know what you mean by the this point.

Our ports on our multiblocks are what expose the capabilities, but they have a backing "multiblock" they know about that houses various information such as size and the like, and while in theory I could in each port write/copy paste a bunch of wrappers to let computer craft call them, it is much easier to just "write" them once instead of for each multiblock.