BMIv3: Extensions #187
BMIv3: Extensions #187
Conversation
…n for major version
PhilMiller
force-pushed
the
PhilMiller/bmi-3-extensions
branch
from
77b3a86 to
befc229
Compare
| :::{tab-item} c | ||
| :sync: c | ||
| ```c | ||
| int get_extension(void *self, char const *name, void **extension_object); |
There was a problem hiding this comment.
Per Austin, I need to specify that this is a pointer-to-pointer to a single output object, and not some sort of array.
There was a problem hiding this comment.
Type erased pointer, callers can reify them through {static,dynamic,reinterpret}_cast in C++, casating syntax in C, Rust std::transmute, or Fortran type(c_ptr). Python doesn't actually need anything special, since it's dynamically typed and dispatched anyway, but functions to get specific extensions could carry type hints to specify return of a particular extension object type.
|
Austin suggested an object-free extension, tentatively named |
PhilMiller
added
the
BMIv3
PhilMiller
force-pushed
the
PhilMiller/bmi-3-extensions
branch
from
befc229 to
1f2c28f
Compare
PhilMiller
force-pushed
the
PhilMiller/bmi-3-extensions
branch
from
19f4c4f to
27576b5
Compare
PhilMiller
force-pushed
the
PhilMiller/bmi-3-extensions
branch
from
e99205b to
86fb07f
Compare
for more information, see https://pre-commit.ci
|
|
||
| ## Shared Conventions and Protocols | ||
|
|
||
| Extensions may describe added constraints or enrished semantics for |
There was a problem hiding this comment.
| Extensions may describe added constraints or enrished semantics for | |
| Extensions may describe added constraints or enriched semantics for |
| extension's name. | ||
|
|
||
| The extension must specify the type signature of each extension object | ||
| it defines, with all of its members. For interoperability, develoeprs |
There was a problem hiding this comment.
| it defines, with all of its members. For interoperability, develoeprs | |
| it defines, with all of its members. For interoperability, developers |
|
|
||
| # BMI Extensions | ||
|
|
||
| An extension of BMI is identified by a unique name string. It could |
There was a problem hiding this comment.
Describe reserved names and namespacing conventions below
| Models implementing BMI are not required to support these extensions, | ||
| nor any others. | ||
|
|
||
|
|
There was a problem hiding this comment.
Describe versioning practices or conventions in some fashion
| The extension must specify the type signature of each extension object | ||
| it defines, with all of its members. For interoperability, develoeprs | ||
| are encouraged to use types and calling conventions that follow the | ||
| practices of core BMI. However, this standard also anticipates that |
There was a problem hiding this comment.
Indexed/numbered variables could help alleviate string ABI interoperability in implementing extensions in various languages.
|
Possible variation on the introspection idea: an extension that asks for a static version of everything that might be available, independent of any specific config file. In that case, the |
No description provided.