Namespaces in ASIL are a combination of C++ namespaces, Java packages, and classes. If Java has a major flaw, it that you can't treat subpackages as part of their parent package. So if you have "org.mydomain.test" and "org.mydomain.test.sub", stuff in "org.mydomain.test" must access the contents of "org.mydomain.test.sub" with the full package name, at least in a using statement.
Namespaces in .NET and C++ are better. Stuff in "System.MyNamespace.test" are implicitly inside "System.MyNamespace". But ASIL goes a step further with derivation of namespaces.
You don't need to use a namespace, but limit this option to small projects where you don't import much. Declaring a namespace means you'll have less risk of a naming collision, both within your project and with other projects you import.
Unlike namespaces in other languages, ASIL namespaces aren't coded. That is, ASIL doesn't have a namespace keyword. You declare them with a namespace definition file which uses XML. (Tat prevents you from having to declare the namespace in each source file.) If you have a namespace, the namespace definition file and all source code within it must be inside a folder whose name matches the namespace name, much like Java packages. So if you have the namespace "x.y.s", you should put your code in the relative path "a/y/s" or "a\y\s" (depending on host OS). However, if the parent namespaces, "a" and "a.y" in this case, have no code of their own, you can use a single folder called "a.y.s".
Name the namespace definition file after the namespace and use the filename extension "asil-namespace". Instead of a separate namespace definition file, you can also declare the namespace inside any XML-based make file.
Below is a table of elements that can appear inside the namespace definition file.
Element | Expected parent | Valid children | Valid attributes | Description |
---|---|---|---|---|
<namespace> |
N/A | <base> , <script-file> (DASIL only |
name , final , module (optional), access |
Top level item! The name attribute should be the fully qualified name of the namespace. Use the final attribute (no value needed) to prevent derivation. If the module attribute is specified, the compiler should issue a fatal error if part of the namespace is included in a different module. See the section on [Modules] for more information on modules. The module attribute has no effect on namespaces derived from this namespace. The <access> identifier lists how code outside the parent of this namespace see this code. It can be public , protected , or private . access is invalid if this is a top-level namespace, but required for nested namespaces. |
<base> |
namespace |
none | name (optional) |
Lists one base fully qualified namespace using the name attribute. You can list as many as needed, each with their own <base> element. |
<script-file> |
<namespace> |
N/A | access , identifier |
Provides a way for a namespace to add restrictions to the accessibility of a DASIL script file. The access attribute specifies this and must be set to public , protected , or private . The other thing this tag does is specify an ASIL identifier as file names aren't valid in ASIL code. That's what the identifier attribute is for. It must be something that isn't used otherwise in that namespace. |
It's considered poor form to derive from namespaces in other projects. Such derivation may cause identifier collisions. Essentially, everything in the the namespace(s) you're deriving from would appear to be inside your namespace.
Like Java, a root namespace is reserved for use by ASIL and platform classes. Most classes needed for operator of ASIL itself, like Object, will be part of the System
namespace or a namespace inside it. Most classes needed to implement the platform (the UI and code that talks to the OS) will be inside System.Platform
where Platform
is the name of the platform.
Name your namespaces like you would a Java package using a name based on your project's URL or something else you know will be unique.
A namespace is a little like a class as previously noted. Normally, anything global are public in nature. But once you put it in namespace, all declarations directly inside the namespace must include an access qualifier. Think of your namespace as a class and your declarations are nested in that class. In fact, ASIL has a class called Namespace that you can access through the reflection system. The access qualifiers public, protected, and private are all available. They mean the same thing they do on a type.
One namespace can contain both SASIL and DASIL source files. The two can even call another. See the discussion in the section [Derivatives] for more information.
Wiki: Derivatives-DASIL
Wiki: Derivatives
Wiki: Home
Wiki: Modules
Wiki: operators-at
No, there isn't a using statement or clause. Nor do I expect to add one. The using statement in C# and Java is something I never understood. I always explicitly use the fully qualified name of any object or class. I consider anything else to be unsafe as you don't know where an identifier is coming from. You also increase the risk of identifer-collisions.