Comments (24)
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
require
ing 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.
Related Issues (6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from allium-cc.