+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: cPlugin_NewLua: why is it Lua-exported? (/thread-465.html)
RE: cPlugin_NewLua: why is it Lua-exported? - xoft - 02-01-2013
Well, let me question this once again. If you want to call plugin A's function F, what do you do? Something along the lines of:
Code:
local PluginA = PluginManager:GetPlugin("PluginA");
PluginA:Call("FnName", Param1, Param2);Why not do this instead?
Code:
PluginManager:CallPluginFunction("PluginA", "FnName", Param1, Param2);No need for a cPlugin object, less code to write... And if MCServer ever supported other scripting languages, it could actually be made to work cross-language. Yuck.
RE: cPlugin_NewLua: why is it Lua-exported? - FakeTruth - 02-01-2013
Because the old style is more object orientated?
RE: cPlugin_NewLua: why is it Lua-exported? - xoft - 02-01-2013
That's the common misconception. "Object oriented" does not mean "has objects", it means "thought in objects". In this case, thinking means "do I really need an object only for the reason of calling a single function on it?" If your answer is "yes", you've been doing too much java
And how much less is the proposed solution object-oriented? You're calling PluginManager's function; PluginManager should be the one who "glues" plugins together, possibly translating from one scripting language to another.My point is, with the proposed changes to the Command API (Command API thoughts, thread https://forum.cuberite.org/showthread.php?tid=765 ) and the WebAdmin API (WebAdmin API thoughts, thread https://forum.cuberite.org/showthread.php?tid=766 ), calling a plugin's function is the only API left for a cPlugin class, if we get rid of it, the whole class (and the entire virtual_method_hooks machinery with its false positives, such as Lua__cEntity) can finally be gone. Isn't that worth fighting for?