jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: Appendix A. Creating a language binding for cairo: Cairo: A Vector Graphics Library jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68: jpayne@68:
jpayne@68:

jpayne@68: Appendix A. Creating a language binding for cairo

jpayne@68:

jpayne@68: While cairo is implemented and C, and has a C API, it is expected jpayne@68: that many users of cairo will be using it from languages other jpayne@68: than C. The glue that connects the core cairo library to another jpayne@68: language is known as a language jpayne@68: binding. This appendix attempts to collect together jpayne@68: issues that come up when creating a language bindings for cairo jpayne@68: and present standardized solutions to promote consistency among jpayne@68: the different language bindings. jpayne@68:

jpayne@68:
jpayne@68:

jpayne@68: General considerations

jpayne@68:

jpayne@68: The naming of the central cairo_t type is a jpayne@68: special exception. The object is “a cairo context” not “a jpayne@68: cairo”, and names such as cairo_t rather than jpayne@68: cairo_context_t and jpayne@68: cairo_set_source() rather than jpayne@68: cairo_context_set_source() are simply jpayne@68: abbreviations to make the C API more palatable. In languages jpayne@68: which have object-oriented syntax, this abbreviation is much jpayne@68: less useful. In fact, if ‘Cairo’ is used as a namespace, then jpayne@68: in many languages, you'd end up with a ridiculous type name jpayne@68: like ‘Cairo.Cairo’. For this reason, and for inter-language jpayne@68: consistency all object-oriented languages should name this jpayne@68: type as if it were cairo_context_t. jpayne@68:

jpayne@68:

jpayne@68: The punctuation and casing of the type names and jpayne@68: method names of cairo should be changed to match the general jpayne@68: convention of the language. In Java, where type names are written jpayne@68: in StudlyCaps and method names in javaCaps, cairo_font_extents_t jpayne@68: will become FontExtents and jpayne@68: cairo_set_source(cr,source), jpayne@68: cr.setSource(source). jpayne@68: As compared to changing the punctuation, and casing, much jpayne@68: more reluctance should be used in changing the method names jpayne@68: themselves. Even if get is usually omitted from getters in jpayne@68: your language, you shouldn't bind cairo_get_source() as jpayne@68: cr.source(). jpayne@68:

jpayne@68:
jpayne@68:
jpayne@68: jpayne@68: jpayne@68: