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.
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 "
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.
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.
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:
- .NET – .NET Framework and .NET Standart 2.0+ (and with that, )
- Windows/Windows (Island)
- Linux/Linux (Island)
- Cocoa/Darwin (Island) – macOS, iOS, iPadOS and tvOS
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.