Namespaces

Namespaces are used to group types into logical subsets – for example for related sections of a larger project, or for types from different libraries. Within each namespace, type names must be unique, but two types of the same name may exist in different namespaces. With that, namespaces are also a great way to help avoid naming conflicts between libraries.

A namespace is either a single identifier (e.g. System), or a list of identifiers, separated by a dot (e.g. System.Windows.Forms).

Types can be referred to from uniquely using their fully qualified name, which is the short type name, prefixed with the namespace name. For example, the Form class in System.Windows.Forms on .NET can be referred to using the full name, System.Windows.Forms.Form.

Types can also be referred to using their short name, if one of the following is true:

  • The code referring to the type is part of the same namespace as the referred-to type.

  • The type's namespace has been used/imported using the uses (Oxygene), using (C#) or import (Swift) keyword.

Declaring Namespaces

Oxygene and C# support declaring namespaces via the namespace keyword.

In Oxygene, the default namespace for any file is specified at the very top of each source file, and all types declared in the file will become part of that namespace. If necessary (although uncommon), a type can be declared with a fully qualified name to override that.

In C#, one or more types can be surrounded by a namespace {} scope, and will become part of that namespace. A source file typically contains one such scope, spanning the entire file, but it is perfectly legitimate for a file to declare multiple namespace scopes, if needed.

namespace Foo;

type  
  MyClass = public class // Foo.MyClass
  end;

  Bar.MyClass = public class // Bar.MyClass
  end;
  //...

namespace Foo
{

  public class MyClass // Foo.MyClass
  {
  }
  
  //...

Swift has no support for declaring namespaces on a per-file or per-class level – see below for details.

Platform Notes

On the Java platform, namespace names are required to be lowercase on runtime level. To make writing cross-platform code easier, the Elements languages will allow you to write namespaces in lower case and mixed case (both when referring to and when declaring them), and will convert them to lowercase for the compiled Java binary. Essentially, namespaces are treated as case insensitive, even in C# and Swift, which otherwise are case sensitive.

One the Cocoa platform, namespaces are not supported by the underlying Objective-C runtime. The Elements languages allow you to fully use namespaces, including having multiple classes with the same name in different namespaces. If two classes exist with the same name, their final names in the binary will be mangled, to avoid naming conflicts on runtime level. This should be transparent to normal use of the class, but will cause side effects if you use Objective-C Runtime APIs to query for or work with classes, or if you are building libraries to be consumed by Objective-C or Apple Swift. It may also affect class names shown in class stacks when debugging.

Language Notes

The Swift language does not currently have support for declaring namespaces. All types you define using the Swift language will become part of the default namespace configured for your project in Project Settings. Swift does have full support for referring to types in different namespaces, both using fully qualified names and by importing namespaces to be in scope via the import keyword.

Namespaces vs. References

It is important to not confuse namespaces with References. While there is often a one-to-one mapping to which libraries contain which namespace, that overlap is arbitrary. A single referenced library can contain types in multiple namespaces (which may or may not be named the same as the library itself), and multiple libraries can contribute to the same namespace.

When using first or third party frameworks and libraries, it is important to know both what namespaces the types you want to use are in, but also which libraries need to be referenced in order to make the types available, as well. For example, all standard Cocoa SDK libraries ship with Elements in library files that match their namespace – Foundation.fx contains the Foundation namespace, UiKit.fx contains the UIKit namespace, and so on. On the other hand, on .NET many core namespaces are located in mscorlib.dll and System.dll.