Hooks

so lets say you have a program that adds virtual folders. clear right, you just make local copies of all the computercraft file programs and modify them to where they are able to interact over the network. easy, dont. but what if you had 3 programs making local copies of the file programs, only the last written version would survive. here is where hooks come in handy. hooks can be made in many diffrent ways, ill show you 2 way, the first one uses api's and the function name would be used as the hook name. for example

virtualfolders.onFolderCreate = function(sPath) return true end

also a way could be through a hook register system like so:

hook.add("onFolderCreate","myhook",function(sPath) return true end)

hook.run("onFolderCreate","mynewfolder") -- this would return true like above

the avantage of the second system is that all the hooks registered with the same hook name will be executed by the system in a particular order. hooks could also be used for permission checks where for example the hook "canUserRunProgram" will be ran to check if a user can run that specific program that is specified in the arguments. also when a hook returns anything it will not run any other functions under that hook type, if nothing is returned the next hook will be executed ect…

so to make it all clear

hook.add("canUserRunFile", "myhook", function(sPath, sName, tArgs) return true end)

teh shell program would run this

hook.run("canUserRunFile", "rom/programs/computer/rednet/mail", "mail", { "host", "hostname" })

this would run through the hooks until a value is returen, in this case true or false. if nothing is return in teh first hook it will move on to the second, so by using this system you gotta make sure you return true ot nothing,

just a little idea to make CC more advanced and personalized because now we have to hack our way around, wich is fine by me, but some prefer to use the legitemate route. :)/>

-wilco

I don't understand what this is at all. Can someone explain this?

I'm not sure that I can - just the "easy, dont" bit had me scratching my head for a moment (I decided it should be "easy, done"). Then we've got a system that involves functions which accept a bunch of arguments, then uses them to… do absolutely nothing, actually, those functions just always return "true" regardless as to what you pass them…

I'm guessing the plan is to dump these "hooks" into a table, then when "hook.run" is called with a given hook name, iterate through the hook names in that table until a match is found. If calling that hook's function returns something (putting aside for now that all hooks will apparently do that under any circumstances), then it stops searching the table.

There are enough possible uses for this sort of thing that I can't say with any certainty which wilcomega is talking about. I'm not sure, for example, whether these hooks are supposed to be executed manually, or automatically (eg whenever trying to interact with a file).

You can do it yourself in Lua. I see no need for this to be implemented CC side.

You've played too much Garrysmod xD

You can add this is a resourcepack to use it for all computers…

so you would make an "api" or more an program which is running all the time…

I dont know if something like hook.add("onFolderCreate" or "onFolderOpen", … ) would work, idk :D/>

i'll try it…

Cloudy, on 02 February 2014 - 02:20 PM said:

You can do it yourself in Lua. I see no need for this to be implemented CC side.

I feel as though this isn't a valid comment. Half the things in the new version are Lua-only things that could have been done Lua-side by the users. The determining factor should be whether it's the right suggestion to get into CC itself, not if the player can do it themselves.

That said, this one I don't believe is right for CC. CC doesn't typically provide APIs for programs to interface outside of their runtime. Running callback functions after the program's execution is quite the opposite paradigm.

ElvishJerricco, on 07 February 2014 - 02:44 PM said:

That said, this one I don't believe is right for CC. CC doesn't typically provide APIs for programs to interface outside of their runtime. Running callback functions after the program's execution is quite the opposite paradigm.

This, and also from experience (I wrote something where you could hook onto events rather than yield for them), the yield-for-event system is actually much nicer than having embedded event listeners (i.e. node.js syndrome). What I ended up realizing is that code becomes messy when doing it like this, especially when you start getting code structures where you listen for a hook inside of a hook listener inside another listener, etc.

Now, that is not to say hooks are completely useless in the ComputerCraft setting. If you really want to have hooks it's super easy to implement by yourself.

Yevano, on 10 February 2014 - 07:04 PM said:

This, and also from experience (I wrote something where you could hook onto events rather than yield for them), the yield-for-event system is actually much nicer than having embedded event listeners (i.e. node.js syndrome). What I ended up realizing is that code becomes messy when doing it like this, especially when you start getting code structures where you listen for a hook inside of a hook listener inside another listener, etc.

Now, that is not to say hooks are completely useless in the ComputerCraft setting. If you really want to have hooks it's super easy to implement by yourself.

What you speak of is known as "Callback hell" =P And yea it's pretty bad. The logic to a program is made non-linear because you write functions that have little to do with your current line of logic in the middle of said line of logic.

ElvishJerricco, on 07 February 2014 - 02:44 PM said:

Cloudy, on 02 February 2014 - 02:20 PM said:

You can do it yourself in Lua. I see no need for this to be implemented CC side.

I feel as though this isn't a valid comment. Half the things in the new version are Lua-only things that could have been done Lua-side by the users. The determining factor should be whether it's the right suggestion to get into CC itself, not if the player can do it themselves.

I agree, that logic is no longer valid after the precedent set by CC1.6.