Go Basics

Users familiar with one or more Elements languages will find a few areas that might work in surprising ways, when adding Go code to their project.

This topic should cover some of these caveats.

Namespaces

Like all Elements languages, Go has full support for Namespaces, including specifying namespaces for your own code and accessing existing code within the namespaces it lives in, for all the platforms. However, the way Go specifies namespaces behaves slightly different than the other languages.

Oxygene, C# and Java specify the full namespace for all types declared in a file at the top, while Swift files do not specify a namespace at all and have all types be part of the RootNamespace set in Project Settings.

Similar to Swift, Go derives the namespace for a file from the RootNamespace, but combines it with the physical folder structure within the project (i.e. relative to the .elements project file) to form the full namespace. The package keyword at the top of the file must match the last part of the namespace.

For example, if a project has a RootNamespace of "mycompany.myproject" and one or more files in a subfolder called "tools", then the package name specified in those files must also be "tools", and the full namespace of types declared in these files will be "mycompany.myproject.tools".

The "Go" root namespace

For .NET and Island-based platforms, Go comes with an extensive Go Base Library (GBL) of commonly used types and functions, ranging anywhere from mathematic algorithms to encryption, network communication and more.

Within .go source files, these types are available via the same namespaces as in Google's Go implementation, e.g. builtin, fmt, crypto, and so on.

Since Elements projects can mix languages, a common scenario is to have some Go code in a project that is predominantly using one of the other languages, and referencing the GBL because the Go code depends on it. In order to not pollute the base name scope with all the Go namespaces, types from the GBL are nested under a virtual "Go" namespace, when accessed from Oxygene, C#, Swift and Java.

In other words, where from Go you might see crypto.md5, the same types will be accessible as Go.crypto.md5 from the other languages

File Name Suffixes

Different than in other languages, file names have relevance for whether a .go file gets compiled as part of a project or not. Go files can have one or more suffixes appended to the base file name with an underscore.

If that suffix matches a platform (such as "_windows"), the file will only be compiled if it matches the platform of the project (or target). If it matches an architecture (such as, "_arm64"), it will only be compiled when building for that particular architecture. Note that this includes platforms and architectures not covered by Elements itself (e.g. a file with suffix "_sparc64" will never be compiled by Elements).

Projects with a suffix of "_test" will only be compiled for Go test projects (which are currently not supported by Elements yet).

Files with unknown suffixes ("_foo") will be compiled as normal.

If in doubt, avoid underscores in names.

Scope of Go Base Library

Our goal is to support the full Go Base Library (GBL) for the following platforms and sub-platforms:

A very limited go.jar with a few base types is provided for Java, but the vast majority of GBL code is not compatible with the limitations of the Java runtime, unfortunately.

The Go Base Library will not be available for Toffee V1 Cocoa projects, since we're planning to have Island/Darwin overtake this target as the default back-end soon (see here for more details).

See Also