PDA

View Full Version : Extension Question



Bidmaron
November 27th, 2016, 22:13
It has been a while since I wrote an extension, and I just need to check because I cannot locate it in the developer documentation:

If I override a manager routine in my extension lua include file, that code will replace the code in the manager, right? And there is no way to invoke the original code (using super or some such) if I just want to intercept the call, check some parameters, and pass control back to the original unless it meets some very specific parameter criteria, right?

dulux-oz
November 28th, 2016, 01:38
Yeap, unlike with the XML templates, lua functions cannot be "supered" from an Extension back to a Ruleset - the whole lua file needs to be reproduced (with appropriate changes) in the Extension

Does that answer you question?

Cheers

Bidmaron
November 28th, 2016, 05:50
That's what I thought, Dulux, but if you need to replace a routine in a manager (in this case, the Table.Manager), do I need to replace each routine in there, or just the ones I need to replace? Since a manager is accessed through Table.xxxx, where xxxx is the name of the routine, how do I even replace it? My guess is that I have to override the entire Manager declaration in my xml so that "Manager" refers to my file and not the original file. So, I think I have to redirect the Table manager in my own xml declaration and duplicate the entire Table.Manager file just to change a couple of lines within one routine. Can you confirm?

dulux-oz
November 28th, 2016, 06:36
Yes, that's pretty much what you have to do.

I suspect that's one reason why there are so many small (<50 lines) lua files - so that they can be "swapped out" easier than if there was only a few big ones.

Moon Wizard
November 28th, 2016, 06:46
Actually, I think that there have been a few extensions that have successfully replaced individual functions within a ruleset. As long as the functions are not defined as local (which none are), then you should be able to replace them. The only caveat is that you still need to be watchful of code updates in the base code, and cross-extension clashes.



function onInit()
TableManager.performRoll = newPerformRoll;
end

function newPerformRoll(...)
...
end


Regards,
JPG

dulux-oz
November 28th, 2016, 06:59
Now that's an interesting idea - and it'll cut down on the code-size as well - hmmmmm?!

That's for that Moon

Bidmaron
November 28th, 2016, 12:37
Actually, I think that there have been a few extensions that have successfully replaced individual functions within a ruleset. As long as the functions are not defined as local (which none are), then you should be able to replace them. The only caveat is that you still need to be watchful of code updates in the base code, and cross-extension clashes.

....

Regards,
JPG

Thanks, MW. It really doesn't make much difference, because you still have to be mindful if you copy the whole file. In fact, it may be less likely that one routine is affected in a change than anything in a whole file. That override trick you mentioned: I never would have come up with that without your input. Muchas gracias, my friend!

Andraax
November 28th, 2016, 14:44
If you just need a wrapper around the original code, save off the current routine and call it. This emulates a call to a base class function. This way you'll get changes in the underlying code as well...


function onInit()
originalRoll = TableManager.performRoll;
TableManager.performRoll = newPerformRoll;
end

function newPerformRoll(...)
...
originalRoll(...);
...
end

(Code has not been tested, but *should* work... :-D )

dulux-oz
November 28th, 2016, 14:55
You realize now I've got to go back through all my code and redo it all, don't you?! :cry:

Nickademus
November 28th, 2016, 16:42
You realize now I've got to go back through all my code and redo it all, don't you?! :cry:

You realize now that you have to figure out the best way to do this and make a tutorial video for the rest of us. :p

Trenloe
November 28th, 2016, 17:34
The other thing to keep in mind with replacing global package functions is that they run outside of the global package. So if the base package has a number of non-public package variables defined as "local" in the package LUA file outside of functions, the replaced function won't have access to these. Thus meaning that it's not always possible to replace an individual function in a global package, as these local package variables can't be accessed without changing the base package, which defeats he objects of overriding package functions. So keep this in mind when looking at overriding a global package function.

Bidmaron
November 29th, 2016, 00:19
Man, this has engendered some great discussions. All great things to think about, and when Dulux makes his video, he will have another excuse for a shameless plug.

Bidmaron
November 29th, 2016, 00:20
Perhaps packages should have a standard set of get... set... functions to provide overriders access to package locals (or at least the ones that have a conceivable usage by overriders).

Trenloe
November 29th, 2016, 00:23
Perhaps packages should have a standard set of get... set... functions to provide overriders access to package locals (or at least the ones that have a conceivable usage by overriders).
If the developer thought they'd need to do this then they could just remove the "local" from the variable definition to make it available outside of the package.

Bidmaron
November 29th, 2016, 00:29
True, Trenloe, but one of the precepts of object-oriented programming, which we are trying to emulate here is that data is encapsulated where manipulated, and, for those who are believers in this programming concept (and I'm not sure I'm really there yet, but I'm starting to come around), the get... set... is more pure to the concept (and lessens possibility of name collisions when people attempt to use the same name out of ignorance of the name's existence somewhere else).

Trenloe
November 29th, 2016, 00:47
True, Trenloe, but one of the precepts of object-oriented programming, which we are trying to emulate here is that data is encapsulated where manipulated, and, for those who are believers in this programming concept (and I'm not sure I'm really there yet, but I'm starting to come around), the get... set... is more pure to the concept (and lessens possibility of name collisions when people attempt to use the same name out of ignorance of the name's existence somewhere else).
I don't think there is any specific programming methodology being adhered to 100% by anyone here. Nor is one (OOP, FOP, RAD, etc.) being touted over the other. I do not subscribe to your suggestion that developers should be made to do a lot more coding to try to fit to a concept that the majority of community developers on this forum would never adhere to. Are you seriously suggesting that developers should go to the hassle of creating get/set functions for each local variable just in case someone might want to access a local variable - purely as a good-practice-programming-concept?

Bidmaron
November 29th, 2016, 01:29
Well, when you put it that way....

dulux-oz
November 29th, 2016, 01:57
You realize now that you have to figure out the best way to do this and make a tutorial video for the rest of us. :p

It's actually in pre-production :p

dulux-oz
November 29th, 2016, 02:07
I don't think there is any specific programming methodology being adhered to 100% by anyone here. Nor is one (OOP, FOP, RAD, etc.) being touted over the other. I do not subscribe to your suggestion that developers should be made to do a lot more coding to try to fit to a concept that the majority of community developers on this forum would never adhere to. Are you seriously suggesting that developers should go to the hassle of creating get/set functions for each local variable just in case someone might want to access a local variable - purely as a good-practice-programming-concept?

Actually, I tend to try to code as OOP & RAD, and there is something to be said about having some "coding standards" in place that everyone "should" follow - I'm thinking about the various Linux-coding standards that most distros follow and which the Linux-coding community generally adhere too - because having a "framework" of standards (even informal ones) and encouraging people to use that framework helps everybody - but I can also see Trenloe's point in that getting coders to do anything the same way as each other is like herding cats, and getting Community/volunteer coders to do it is like herding saber-toothed tigers!

Still, it might be worth considering and having a discussion about this between the Devs and Community Devs - if we can get the majority of the tigers to at least walk in the same general direction then we'll start to see the benefits of doing so sooner rather than later - just like the Linux-coders have and just like a plethora of other Open Source and Community-driven/supported projects have.

Just a thought :)

Cheers