0
|
1 This document intends to layout a style to follow for language bindings,
|
|
2 depending on the nature of the language.
|
|
3
|
|
4
|
|
5 Naming
|
|
6 ------
|
|
7
|
|
8 If possible and no name clashes exist with other bindings, use the language's
|
|
9 shortest name or file suffix and append 'dc' or 'dyncall'. E.g.:
|
|
10 Ruby: rbdc
|
|
11 Go: godc
|
|
12 ...
|
|
13
|
|
14
|
|
15 Code style
|
|
16 ----------
|
|
17
|
|
18 * Imperative:
|
|
19
|
|
20 - Object oriented or prototype:
|
|
21
|
|
22 Create 2 objects, one as a handle to each external library (e.g. extlib), one as a handle to a callvm
|
|
23
|
|
24 - Without objects:
|
|
25
|
13
|
26 Wrap dyncall as close as possible, exposing function by function
|
0
|
27
|
13
|
28 - Statically typed (and no reflection/RTTI):
|
0
|
29
|
|
30 Expose all dcArg, etc. calls
|
|
31 Expose formatted call ('...') if possible, but as ArgF (instead of CallF), b/c return type is statically typed
|
|
32
|
13
|
33 - with reflection/RTTI:
|
0
|
34
|
|
35 Write a single call function and let users pass arguments, directly - if needed for type-conversion, this
|
|
36 should be done via call signature
|
|
37
|
|
38
|
|
39
|
|
40 * Functional:
|
|
41
|
13
|
42 ... nothing really different from imparative guidelines above?
|
0
|
43
|
|
44
|
|
45
|
|
46 * Other language features
|
|
47
|
|
48 - Namespaces/modules/packages
|
|
49
|
13
|
50 Use and name dyncall or dc (prefer former)
|
0
|
51 Use casing depending on language requirements (e.g. 'Dyncall' for ruby as modules are const)
|
|
52
|
|
53 - Function overloading or default arguments
|
|
54
|
|
55 Use if available to define things like CallVM stack size; use independently named functions, otherwise
|
|
56
|