Users familiar with one or more other 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 as a
mycompany.myproject and one or ore 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
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.
.go source files, these types are available via the same namespaces as in Google's Go implementation, e.g.
crypto, and so on.
Since Elements projects can mix languages, a common scenario is to have some Go code in project that is predominantly using one of the other languages, and referencing the GBL because the Go code depends on it.
In other words, where form 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. "_sparc64").
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 is 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.