Naming Conventions ¶

G-Golf is, or at least tries to be, consistent in the way ‘things’ are being named, whether the functionality being ‘exposed’ is from an imported GNOME library or is part of a G-Golf’s core reference module.

GNOME Libraries ¶

When G-Golf imports a GNOME library, its classes, properties, methods, functions, types and constant are renamed, which is achieved by calling g-name->class-name and g-name->name appropriately.

As described in their respective documentation entry, as well as in the Customizing G-Golf section, G-Golf offers a way to either ignore or partially customize the renaming process.

  ^_ Classes

GNOME libraries classes are imported as GOOPS classes (the Guile Object Oriented System, see GOOPS in The GNU Guile Reference Manual), and their respective name is given by the result of calling g-name->class-name, for example:

GtkWindow ⇒ <gtk-window>
ClutterActor ⇒ <clutter-actor>
WebKitWebView ⇒ <webkit-web-view>(5)
...

  ^_ Properties

GNOME libraries class properties are imported as GOOPS class slots, and their respective name is given by calling g-name->name. Each property slot defines an init-keyword and an accessor, following G-Golf’s accessors naming conventions (See GOOPS Notes and Conventions).

As an example, the <gtk-label> class has a label slot, with the #:label init-keyword and !label accessor.

  ^_ Methods

GNOME libraries methods are imported as GOOPS methods, the name of which is obtained by calling g-name->name.

Unless otherwise specified (see Customization Square - GI Method Short Name Skip), as it imports a GI typelib, G-Golf creates a method short name for each imported method, obtained by dropping the container name (and its trailing hyphen) from the GI typelib method long name.

For example, the <gtk-label> class, which defines a gtk-label-get-text method, would also define, using G-Golf’s default settings, an get-text method.

  ^_ Functions

GNOME libraries functions are imported as procedures, renamed by calling g-name->name. For example:

gtk_window_new ⇒ gtk-window-new
clutter_actor_new ⇒ clutter-actor-new
...

  ^_ Enums, Flags and Boxed types

GNOME libraries enums, flags and boxed types are renamed by calling g-name->name (and cached, See Cache Park section).

Enum and flag type members are renamed by calling g-name->name. To illustrate, here is an example:

,use (g-golf)

(gi-import-by-name "Gtk" "WindowPosition")
⇒ $2 = #<<gi-enum> 5618c7a18090>

(describe $2)
-| #<<gi-enum> 5618c7a18090> is an instance of class <gi-enum>
-| Slots are:
-|      enum-set = ((none . 0) (center . 1) (mouse . 2) (center-always . 3) (center-on-parent . 4))
-|      g-type = 94664428197600
-|      g-name = "GtkWindowPosition"
-|      name = gtk-window-position

G-Golf Core Reference ¶

  ^_ Procedures and Variables

G-Golf procedure names that bind a Glib, GObject or GObject Introspection functions (always) use the ‘original’ name, except that every _ (underscore) occurrence is replaced by a - (hyphens). For example:

g_main_loop_new
⇒ g-main-loop-new

g_irepository_get_loaded_namespaces
⇒ g-irepository-get-loaded-namespaces

G-Golf also comes with its own set of procedures, syntax and variables, aimed at not just reading a typelib, but making its functionality available from Guile. Naming those, whenever possible, is done following the ‘traditional way’ scheme name its procedures, syntax and variables. For example:

• procedure names that start with call-with-input-, call-with-output- followed by a Glib, GObject. Gdk or GI type, such as:

  call-with-input-typelib
  

• syntax names that start as with- followed by a Glib, GObject, Gdk or GI type, such as:

  with-gerror
  

When an ‘obvious’ name can’t be find ‘on its own’, or to avoid possible conflict outside G-Golf⁶, then the name starts using a g- prefix (when the procedure context is GNOME in general) or gi- prefix (when the procedure context is GI more specifically), and equally for variables, using %g- or %gi-.

  ^_ Types and Values

G-Golf variables that bind Glib, GObject and GI types and values use the same convention as for procedures, except that they always start with % and their original type names are transformed by the same rules that those applied when calling g-studly-caps-expand.

For example, from the GIBaseInfo section:

GIInfoType
⇒ %gi-info-type