Skip to content

Naming

Jump to bottom
Randall O'Reilly edited this page May 7, 2019 · 6 revisions

Here are the emergent-specific naming conventions -- please use these to keep the code as readable and consistent as possible!

First, we follow all the general Go conventions:

And here are some additions for the GoKi framework:

The two most important from the GoKi page are:

Formal names vs. Nicknames

There are generally two "views" of a given structural entity like a Layer:

  • A Go interface that describes a set of methods, and is the way to create a virtual function calling pattern in Go, so that we can efficiently have more specialized versions of a given overall algorithm. emer defines overall structural interfaces for emer.Network and emer.Layer that allow e.g., the netview.NetView to be applied to any kind of network.

  • The specific struct type that implements the interface, e.g., leabra.Layer.

The naming problem arises in the clash between the field names for the struct vs. the accessor methods onto those fields. e.g., you can't have both Name() in the interface and a field named .Name in the struct.

The solution we've adopted is to use "nicknames" for the struct (e.g., Nm), and "formal" names for the interface methods. The initial draft of emer did not follow this but this was corrected in 5/2019..

Accessors

We generally provide 2 methods for accessing elements in cases that might fail (e.g., by name):

  • ThingByName(name string) *thing
  • ThingByNameTry(name string) (*thing, error)

The first one should be used if you know the thing should exist -- in which case you can convert the return value (which is often an abstract interface type) directly into the type you know it should be. That is much more efficient. The second one should be used if it is acceptable for the thing not to exist -- you can then print out or popup a dialog for the error value.

Leabra-specific naming issues

See the Leabra README for specific naming conventions for that algorithm.

test

Clone this wiki locally