https://github.com/hongyuanjia/dyncall-bindings

Read-only mirror of dyncall bindings source code from https://dyncall.org/pub/dyncall/bindings/. See https://dyncall.org for details
https://github.com/hongyuanjia/dyncall-bindings

Last synced: about 1 month ago
JSON representation

Read-only mirror of dyncall bindings source code from https://dyncall.org/pub/dyncall/bindings/. See https://dyncall.org for details

• Host: GitHub
• URL: https://github.com/hongyuanjia/dyncall-bindings
• Owner: hongyuanjia
• Created: 2022-12-16T02:17:47.000Z (about 2 years ago)
• Default Branch: master
• Last Pushed: 2022-12-16T02:18:12.000Z (about 2 years ago)
• Last Synced: 2024-10-13T19:09:00.613Z (2 months ago)
• Language: R
• Homepage: https://dyncall.org
• Size: 883 KB
• Stars: 0
• Watchers: 2
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.txt

Awesome Lists containing this project

README

        
This document intends to layout a style to follow for language bindings,

depending on the nature of the language.

Naming

------

If possible and no name clashes exist with other bindings, use the language's

shortest name or file suffix and append 'dc' or 'dyncall'. E.g.:

  Ruby: rbdc

  Go:   godc

  ...

Code style

----------

* Imperative:

  - Object oriented or prototype:

      Create 2 objects, one as a handle to each external library (e.g. extlib), one as a handle to a callvm

  - Without objects:

      Wrap dyncall as close as possible, exposing function by function

  - Statically typed (and no reflection/RTTI):

      Expose all dcArg, etc. calls

      Expose formatted call ('...') if possible, but as ArgF (instead of CallF), b/c return type is statically typed

  - with reflection/RTTI:

      Write a single call function and let users pass arguments, directly - if needed for type-conversion, this

      should be done via call signature

* Functional:

  ... nothing really different from imparative guidelines above?

* Other language features

 - Namespaces/modules/packages

     Use and name dyncall or dc (prefer former)

     Use casing depending on language requirements (e.g. 'Dyncall' for ruby as modules are const)

 - Function overloading or default arguments

     Use if available to define things like CallVM stack size; use independently named functions, otherwise