UnofficialCrusaderPatch / UnofficialCrusaderPatch3

Development for the dll Injection approach
GNU General Public License v3.0
11 stars 2 forks source link

[CORE] public versus protected module functions #81

Closed gynt closed 9 months ago

gynt commented 9 months ago

Since modules run verified code, and plugins do not, and currently all functions a module exports are exposed to a plugin, I think we want to make a distinction between which exported functions can be used by plugins, which by modules, and which by all.

Per default, only other modules can use exported functions.

Proposal:

Option 1

return {
  enable = function(self, config) end,
  disable = function(self, config) end,
  sane_function = function(self, a, b, c) end,
  insane_function = function(self, a, b, c) end,

  exports = {
    -- module accessible functions: all by default
    protected = {"sane_function", "insane_function",},
    -- functions accessible by all: subset of functions
    public = {"sane_function",},
  },
}

Option 2

Looks nicer and appears more compatible with how things are currently written (almost no functions are currently meant to be used by plugins via lua, except files.overrideFileWith()). However, it breaks the logic regarding object-oriented programming (self).

local protected = {
  enable = function(self, config) end,
  disable = function(self, config) end,
  sane_function = function(self, a, b, c) end,
  insane_function = function(self, a, b, c) end,
}

local public = {
  sane_function = protected.sane_function,
}

return protected, public

Option 3

Best of option 1 and 2?

local namespace = {
  enable = function(self, config) end,
  disable = function(self, config) end,
  sane_function = function(self, a, b, c) end,
  insane_function = function(self, a, b, c) end,
}

local exports = {
  public = {
    "sane_function",
  },
}

return namespace, exports

I favor Option 3

gynt commented 9 months ago

I went for option 3