Some thoughts for consideration, but not a proposed architecture.
As you recognise, the functional model and the ‘object’ model organize data and code differently. Both can encapsulate code and data, both can represent forms of polymorphism, object orientation favours inheritance whereas the functional model favours composition.
In Elixir (erlang, BEAM, OTP) the fundamentals exist:
- For modules,
module.module_info/1) can be used to identify the functions that are exports and much more. For example:
attributes: [vsn: ],
options: [:no_spawn_compiler_process, :from_core, :no_core_prepare,
md5: <<48, 41, 74, 113, 137, 7, 188, 147, 27, 101, 152, 222, 121, 121, 204,
- You can also leverage the info/1 function that is added to each module at compile time
Elixir provides behaviours and protocols to support a form of polymorphism.
Behaviour is a way to enforce a consistent interface to a module and therefore can be used to define different concrete implementations for an abstract concept. In Elixir, for example, the Calendar behaviour defines the functions required to be implemented in any module that supports the
Calendar behaviour. You can see if a module implements a behaviour:
[vsn: , behaviour: [Calendar]]
You can also find the callbacks defined for a behaviour with the following although this is probably of limited use since if you know the behaviour then you know the callbacks. And since you can’t really introspect the parameters or identify the semantics of the functions there’s not really anywhere to go.
iex> Calendar.behaviour_info :callbacks
Protocols are commonly defined to present a standard functional interface to data types (including, and very commonly, structs). The Inspect protocol is probably the most well known but its easy to implement your own protocol and implement it for the types you require.
Application to extensions
In considering extensions, behaviours and protocols would likely form the basis of the architecture. Introspection of a given module can be used to determine if it implements a given behaviour.
Module loading is, as @hauleth noted, a matter of having the BEAM file in the code load path. To be more deliberate you can use
System-wide discovery of which modules implement a given behaviour is less straight forward and this article and the accompanying library behaviour-relfection may give you additional ideas.
With the tools above you could try a naive extension approach by:
- Load a user-supplied BEAM file and capture its module name from the file name
- Check if the module implements the expected extension behaviour
- Register the module into your core application callback mechanism (this part up to you)