David Haley said: This isn't answering the question. What prevents you from having a full object interface without affecting the existing interface?
More OO isn't the only thing you can do under this setup - it's just the most obvious thing. (Yes, I know I'm not suggesting any other things. I just don't really feel the need to prove my plan's worth, and I have to get to Karate.)
David Haley said: You could even create some kind of Lua object that had an entry per supported plugin callback, with the difference that the parameters would be richer userdata rather than strings etc. So it wouldn't even look that different as far as script authors are concerned.
Hum. Can you explain this? A Lua object that had an entry per supported plugin callback... I'm not sure what that means.
David Haley said: I get the impression that you're going straight to the most complex solution but without even really considering the simpler solutions or what the practical tasks and goals are.
Well, do keep in mind, I came at this from a refactoring angle. This was just one of the things you could theoretically do with such a refactoring. It wasn't really like "The Lua interface reeks in MUSHclient... lets make it better by revamping the whole scripting engine support!"
I also don't think it's the most complex solution, really. The actual operations of the current WSH and Lua methods won't change except with regards to the parameters each method takes. At the most basic level, I'm (1) splitting Lua and WSH code away from each other, and (2) splitting the myriad uses of CScriptEngine::Execute() into singular methods.
As an example, to make it easier when I was on my second iteration (i.e. working out the practical difficulties by diving into the code headfirst), I defined a private method Invoke() on the WSH interface, which took a DISPPARAMS reference just as the original Execute() did. The three new Execute methods - as I hadn't come up with the one-per-callback plan - took their arguments, stored them in a DISPPARAMS, and called Invoke() with it. It was trivial to take code calling Execute() and move the DISPPARAMS manipulation into an Execute method. What I left behind was singular and unified: it didn't care what scripting engine was involved, as long as it got the arguments.
(What really killed that second iteration is that the MXP error callback takes its arguments differently based on whether you're using Lua or WSH. My current plan solves that, and it's tidy to boot.) |