blob: 542271e1bebbd2611a49843df6b19ba6ad6016ce (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
Service Provider Interfaces
===========================
Use cases:
* Optional dependencies
* Load-time multiple implementation
* Something like symbol interposition (e.g. fakeroot)
* Things that can be overridden in an arena / Runtime multiple implementation
* Perhaps even for things like Java/C#-style interfaces?
Syntax?
* Fully hidden? I.e. "normal" function/method calls.
* Fully hidden, but allow only calls "on" an arena-allocated object?
* Special syntax?
spi(arena_obj).do_stuff(x, y, z)
do_stuff(spi(arena_obj), x, y, z)
* Or declare only certain methods as SPI methods?
func overridable arena Thing.work()
func overridable do_stuff(arena)
- Problem: Sometimes an API can ONLY be overridden as a whole!
(for example: resource aquisition + release)
- Better use "libraryspec" for these kinds of things?
And then allow an implementation to be selected for the arena
(but how to handle recursive invocations?)
- Or something like interfaces? With some kind of default impl?
Problems:
* Performance of calls to exported functions, if they can be overridden.
* Possible bypassing of access checks if the functions used by the access
check can be overridden by other code (i.e. untrusted code).
- UNLESS the code loses ALL privileges.
Alternative solutions:
* Optional dependendencies: YES. These would require a boolean check
(similar to option types), and would require some special syntax
to indicate that a function requires it.
- E.g.: depends "PKGNAME"
- Maybe also: depends "PKGNAME" >= "1.0"?
- And have \depends with "upto"?
- What should the syntax for checking be?
Perhaps module_available(arena, "PKGNAME") ?
* Load-time multiple implementation: YES. Can be controlled with
symlinks on Linux and some loader configuration file for
system-independent configuration.
|
