Need some help understanding superloading

[nate]

I think that's about as clear as its possible to be, actually; thanks.

Your linked explanation seems like a perfectly reasonable way to handle talent modification, although I could imagine that there's other stuff in data for which I might have trouble finding an identifier. (I was actually thinking about making a string out of the talent definition, manipulating the string, then doing my altered string, and was all googly about my potentially limitless power.)

In your linked post, you describe an undocumented hook. Is there a complete list of hooks anywhere? Is there a way that I could search the game code (maybe the svn code?) to identify all hooks?

Even though I don't imagine inheritance to be important to anything I might do, I certainly didn't understand it before, and feel like I've got a bit of a grip on it now. At least enough to trace inherited elements.

[lukep]

In your linked post, you describe an undocumented hook. Is there a complete list of hooks anywhere? Is there a way that I could search the game code (maybe the svn code?) to identify all hooks?

This should work:http://git.develz.org/?p=tome.git&a=sea ... riggerHook

[nate]

Thanks, that's perfect! (And I was wondering where to find a changelog... edit:which that link answers, just to be perfectly clear)

[nate]

Okay, another question:

I've run into trouble when superloading functions that call another function from an absolute name rather than a relative name-- _M:init in mod/class/uiset/minimalist.lua, for example, calls UISet.Init(self), causing an error ("Lua Error: .../widgettemplate/superload/mod/class/uiset/Minimalist.lua:32: attempt to index global 'UISet' (a nil value)").

Well, at least, that's what seems different about this call, so I figure that's what's responsible for the error. That's with a basic superload-- loadPrevious followed by a redefinition of _M:init that's identical to the old definition. Overloading (with the entire contents of minimalist.lua) doesn't cause an error. When the original definition is instead assigned to a base_init and called from that, no error.

Is this because of path issues? What's the best way around this? (Technically speaking, do superloads even need to go into a superload directory? The code suggests that loadPrevious and redefinition could occur anywhere.)

[aardvark]

I've run into trouble when superloading functions that call another function from an absolute name rather than a relative name-- _M:init in mod/class/uiset/minimalist.lua, for example, calls UISet.Init(self), causing an error ("Lua Error: .../widgettemplate/superload/mod/class/uiset/Minimalist.lua:32: attempt to index global 'UISet' (a nil value)").

If you look at line 22 of v1.0's Minimalist.lua, you'll see the line

Code: Select all

local UISet = require "mod.class.uiset.UISet"

which defines a local variable. That variable is local only to that file. It's not part of the class definition table. loadPrevious() can't and doesn't pull that into your superloaded file. You have to require() those kinds of file dependencies into local variables in your own superloaded files, too.

(Technically speaking, do superloads even need to go into a superload directory? The code suggests that loadPrevious and redefinition could occur anywhere.)

Yes and no. They have to go into superload/ or they won't have loadPrevious() defined for them, but you could change the argument to loadPrevious() to any class table you wanted. That's just heartburn waiting to happen, though, and more work than making a couple subdirectories.

[nate]

Ahh-- I ran into a bunch of problems until I realized that scope didn't extend into superloads. I probably missed UISet because of the "require"-- that's one of those things that, since I don't know what it does, I glaze over.

Have you the energy to explain what "require" does? Is it specific to Tome, specific but common practice, something general to Lua?

(And don't worry, I'm not going to superload anywhere else, although the ability to edit functions on the fly is one of those things that seems really appealing and powerful to me, even if I don't have any application in mind. Yet. )

[aardvark]

Have you the energy to explain what "require" does? Is it specific to Tome, specific but common practice, something general to Lua?

It's a Lua function for loading files.

[nate]

Wow. I was just about to sit down and figure out how to start a library of my own functions. You just saved me a lot of effort. Thanks again.

[nate]

Okay, another question: what about multiple superloads? If two add-ons superload the same file, do they superload in series? Like, one add-on superloads the default code, then the second add-on superloads the superloaded code?

I'm asking because I'm trying to design code that's friendly for people that want to do the same thing later. Here's an example:

Code: Select all

local _M = loadPrevious(...)
local base_setupCommands = _M.setupCommands
--function from loadPrevious that I'm inserting a new function into
local base_addNewMenuItems = nil
--declaration just to make sure I keep my base local, don't want it overwriting earlier superloads, don't want it overwritten by later superloads using same code
if _M.addNewMenuItems then base_addNewMenuItems = _M.addNewMenuItems end

function _M:addNewMenuItems(list)
	list[#list+1] = {"Test", function() game.logSeen(game.player, "Menu test!") end}
	if base_addNewMenuItems then return base_addNewMenuItems(self, list) end
      --percolate through superloads that are doing things the same way I am
end

Is that the right way to do things?

[HousePet]

I'm not sure you need to worry about keeping the base local.

I use the format on the wiki that is supposed to allow for chaining superloads.
I haven't seen anything that would suggest it doesn't work.

(and if it doesn't, we just blame DarkGod)

[nate]

Is there something specifically about chaining superloads? That affect the same function, or use the same function? I'm concerned that if base_function is used by two addons, that the second will superload from the first, reassigning the address of the globally scoped base_function, and the first's function will end up calling a base_function that now refers to itself-- infinite loop, whee.

I guess I could just design it and see if it works or breaks. That seems to be what I always end up doing anyways.

[HousePet]

Its sitting at the bottom of http://te4.org/wiki/addons

It suggests you replace the function you wish to superload with a wrapper function that contains you code and the original function.

[nate]

I did some testing, just to verify-- global base_function, in two superloads, works just fine, like you say.

But _M:base_func in two superloads does the infinite loop thing, so the "if _M:newfunc then base_newfunc = _M:newfunc end" and/or "if base_newfunc then return base_newfunc end" structure for chaining superloads doing the same thing seems like a good idea.

Must be a scope issue-- I don't yet fully understand when scope is going to penetrate.