GOOPS Notes and Conventions ¶

G-Golf extensively uses GOOPS, the Guile Object Oriented System (see GOOPS in The GNU Guile Reference Manual), in a way that is largely inspired by Guile-Gnome.

Here are some notes and the GOOPS conventions used by G-Golf.

  ^_ Slots are not Immutable

Except for virtual slots, there is currently no way to effectively prohibit (block) a user to mutate a goops class instance (one can always use slot-set! instance slot-name value)⁷.

However, you will find a few places in this manual using phrase excerpts like ‘instances of this <class> are immutable’, or ‘this <slot> is immutable’. In these contexts, what is actually meant is that these (insances or slots) are not meant to be mutated. Doing so is not only at your own risks, but likely to cause a crash.

  ^_ Merging Generics

In G-Golf, generic functions are always merged (see Merging Generics in The GNU Guile Reference Manual).

Users are (highly) recommended to do the same, in their repl, application/library modules and script(s). In its modules - those that import (oop goops) - G-Golf uses the following duplicate binding handler set:

  #:duplicates (merge-generics
		replace
		warn-override-core
		warn
		last)

In a repl or in scripts, these maybe set - after importing (oop goops) - by calling default-duplicate-binding-handler:

(use-modules (oop goops))

(default-duplicate-binding-handler
    '(merge-generics replace warn-override-core warn last))

G-Golf regular users should consider adding the above lines to their $HOME/.guile or, when working in a multi-user environmet, should consider adding those lines the file named init.scm in the so-called Guile global site directory⁸, here (evaluate the following expression in a terminal): guile -c "(display (%global-site-dir))(newline)".

  ^_ Accessors Naming Convention

In G-Golf, all slots define an accessor (and no getter, no setter), the name of which is the slot-name prefixed using !. For example:

(define-class <gtype-class> (<class>)
  (info #:accessor !info
        #:init-keyword #:info)
  ...)

The principal reasons are (not in any particular order):

• It is a good idea, we think, to be able to visually (and somehow immediately) spot and distinct accessors from the rest of the scheme code your are looking at or working on.
  
  
• Accessors are exported, and with this convention, we almost certainly avoid all ‘name clashes’ with user namespaces, that otherwise would be extremelly frequent⁹.
  
  
• Users quite often want or even need to cash slot values in a closure. By using this ! prefixing convention, we leave users with the (quite usefull) possibility to name their local variables using the respective slot names.
  
  
• Accessors may always be used to mutate a slot value (except for virtual slots, for which you can ‘block’ that feature), like in (set! (!name an-actor) "Mike"). In scheme, it is a tradition to signal mutability by postfixing the procedure name using the ! character.
  
  
• Accessors are not procedures though, there are methods, and to effectively mutate a slot value, one must use set!. Therefore, prefixing makes sence (and preserves the first reason announced here, where posfixing would break it).
  
  
• We should also add that we are well aware that Java also prefixes its accessors, using a . as its prefix character, but GOOPS is radically different from Java in its design, and therefore, we really wanted another character.