Module Structure Discussion about allium-cc HOT 24 CLOSED

Linear Module Structure implemented in 615d763.

from allium-cc.

That just sounds weird.
How about import?

from allium-cc.

Here's an example of how MR-Module interaction would occur:

local plugin-A = allium.register("plugin A", "Demo Plugin A")
plugin-A.module({ -- This function `.module` gets overwritten by the module, just an FYI
  test = "This is a message from Plugin A"
})
local module-B= require("plugin-b") -- Allium plugin names are lower case with spaces replaced with dashes
print(module-B.test..", but printed from in plugin A.")
print(module-B.another-test..", and naturally it works from within plugin A.")

local plugin-B = allium.register("plugin B", "Demo Plugin B")
plugin-B.module({
  test = "This is a message from Plugin B"
})
local module-A = require("plugin-a") 
plugin-B.module.another-test = "This is a message from plugin B, after we require plugin A"

print(module-A.test..", but printed from in plugin B.")

These aren't tested but should work. Hell you may be able to get away with putting them in the same file...

from allium-cc.

I personally think that if you have mutual recursion between two modules, that's a bug and they're too tightly coupled.

from allium-cc.

I agree with osmarks. there should be no reason for mutual recursion. Instead just decouple more things.

from allium-cc.

What are the pros and cons of a recursive implementation over a linear one?
Why would this be considered a bug if it works as intended ?

from allium-cc.

Pros:

• Already implemented (not really one)
• Allows for 2 plugins to use each others modules without crashing and burning

Cons:

• Requires that modules be applied before requiring anything (as can be seen in the demo)

It works as intended, and is useful. If Player A and Player B make plugins, and they both at the same time decide they want to use an aspect of each other's API, they can without things crashing and burning. In a world where everything was linear, this would crash one of their plugins.

from allium-cc.

So the problem that I'm having currently with making the structure linear is that I have no way of detecting what plugin is requesting the module. Plugins are loaded on execution, not compilation meaning that multiple can be loaded in one .lua file. Because both modules and plugins are dynamic, and more variables than static files, would it be acceptable to not use require at all, but a custom function that is loaded per plugin that returns a module, but errors if the plugin who's module is being requested requires the plugin that's requesting it. (Basically if plugin A requires plugin B, plugin B would error if it tried to require plugin A). It would probably be a method returned by register, something like .request, or maybe I'll stick with .require. I guess that's open for discussion as well

from allium-cc.

Maybe you can go a similar route as flask, because on flask if I wanted to host a webpage at /hugeblank you would do:
@app.route("/hugeblank")
(Define function to be called when someone goes to /hugeblank here that returns what goes on the page)

from allium-cc.

That's the general premise of Lua's require, where the name of the file is what you request to return "what goes on the page". Basically I would be doing what require does, but per-module.

from allium-cc.

I guess at this point I can discuss the pros and cons of each structure:

Mutually Recursive
Pros:

• Built right into require, no problem.
• No real need to worry about your plugin crashing and burning. As long as the target plugin you're requesting exists, even if the target is requiring the requesting plugin.

Cons:

• If it fails the require it goes into looking for files eek. I guess require implementation is kind of a neutral.
• It requires a tighter plugin structure, tighter than lua already is. All modules need to be registered before any requireing can occur.

Linear
Pros:

• It behaves like literally everything else in Lua
• Not smacked into require like the other model
• Plugin structure can remain as janky as you wish as long as it compiles

Cons:

• No guarantee that the plugin you may want to load is, in its development, going to require your plugin. If it does, one or both of the plugins will crash and burn.
• It's not, and cannot be built into require due to the checking that needs to occur.
• Requires a lot more checking in order to make sure that the plugins aren't trying to load each other

from allium-cc.

Can't you, instead of having plugins "require" each other, have them provide an api with allium as middleman? Maybe something like message passing. idk

from allium-cc.

That's basically what .require returned by register in my case is doing. A plugin uses another method given by register, .module to provide Allium with an API to then give when a plugin uses their own .require method.

from allium-cc.

Going to stick with the Non-Mutually Recursive module structure. Thanks all for your input!

from allium-cc.

I just don't think using require for this is a good idea. Why should one plugin require the source file of another one; that would execute the file again and have it register the plugin another time.

Instead allow every plugin to make stuff available through Allium.

from allium-cc.

It's not requiring the source file, see the documentation. It returns whatever the plugin provides in the .module call on loading.

from allium-cc.

Then why is it called require. That just adds confusion

from allium-cc.

@MagnificentPako What do you suggest it be called? I'm open to suggestions

from allium-cc.

LoadModule()?

from allium-cc.

@Indianajaune I would prefer it be one word, but worth considering.

from allium-cc.

Also... Why the hell is it a global function. If you were to call it allium.require it would be fine IMO. Just please don't mess with the original require, that will only lead to confusion.

from allium-cc.

It's not a global function? It's given on registering a plugin.

local plugin = allium.register("another-plugin") -- Register a plugin named 'another-plugin'
plugin.module({ -- A demo module
  test_method = function(str) -- A test function within the module
    return str.." used another-plugin's test_method"
  end
})
-- This plugin could also have a bunch of commands, but I'm too lazy to demonstrate that

local plugin = allium.register("demo-plugin") -- Register a plugin named 'demo-plugin'
local other_plugin_module = plugin.require("another-plugin") -- Load the module from 'another plugin'

local trigger_func =  function(name)  -- Define the function for the command
  allium.tell(name, other_plugin_module.test_method(name)) 
end

-- Create the command !demo-plugin:trigger
plugin.command("trigger", trigger-func, "A demo on how to make a pair of plugins, then load a module")

-- This plugin could also have a module, but it wouldn't be able to be required from 'another-plugin'.

You may have the linear structure mixed up with the mutually recursive structure. With the mutually recursive structure I didn't need to know which plugin was loading what, but since I implemented the linear one, in order to determine which plugin is loading what (you can have multiple plugins contained within one file), it had to be provided on register.

See here: https://hugeblank.github.io/Allium-wiki//#!docs/register-api.md

from allium-cc.

@hugeblank need()

from allium-cc.

Definitely like that one, Thanks @osmarks!

from allium-cc.