Imports?

Import?

import com.mycode.MyClass //MyClass will be imported with a short name of: MyClass
import com.mycode.MyClass as ImportedClass //using 'as' enables us to override the short name of the asset imported

Recall that importing an asset allows us to use it within having to refer to the fully-qualified name of the asset. So the following are equivalent:

import com.mycode.MyClass as ImportedClass //using as enables us to override the short name of the asset imported

inst1 = new ImportedClass()//mapped to: com.mycode.MyClass behind the scences 
inst2 = new com.mycode.MyClass()

From Import?

From import is particularly useful where we wish to import more than one asset from the same package path:

from com.mycode import MyClass 
from com.mycode import MyOtherClass, MyOtherClass2

//As with conventional import we can override the short names of the imported assets:
from com.mycode import MyClass as ImportedClass
from com.mycode import MyOtherClass  as ImportedClass, MyOtherClass2  as ImportedClass2

Star Import?

If we wish to import all assets under a package name path, then we can use the star notation:

from com.mycode import *
import com.mycode.*

Import star should be used with careful consideration as it can easily cause problems with overuse as short names may conflict with one another.

Import sites?

The variants of the aforementioned import statements may be used at any point in Concurnas code. They follow the normal scoping rules:

def myfunc(){
  from com.mycode import MyClass
  mc = MyClass() //MyClass can now be used within the { } and any nested scopes
  if(acondition){
    mc2 = MyClass() //MyClass may be used here
  }
}
//MyClass may not be be used from this point onwards as this is outside the imported scope

Most of the time however, convention dictates that imports are best placed at the top of a module code file for global usage inside said module.

Using imports?

The import statement is "side effect free" - that is to say that no code will be directly run at the point in which an asset is imported, instead this only takes place when the asset is used for the first time. This behaviour is in contrast to the likes of Python which, at the point where code is imported, any top level code present within the imported script will be executed.

It is not essential to use import statements in one's code, one could simply refer to the fully-qualified paths of the assets of interest. For example, instead of importing java.util.ArrayList for use in a new object instantiation, one could just use the fully-qualified name, i.e: mylist = new java.utils.ArrayList<String>()

Packages?

An asset's fully-qualified importable package name is a function of its name within the module it's declared within, the module name and its path relative to the root of compilation at compilation time. Note that Concurnas does not have a package keyword, instead it relies upon the directory structure relative to the root of compilation in order to determine this. So for example, using a conventional directory structure (found in almost all operating systems) when we compile our code if our root was set to /home/project/src and our code within this root, in a directory structure ./com/mycode.conc (i.e. file mycode.conc is within subdirectory com containing the class definition MyClass) - then the fully qualified package name of the class at compilation time would be com.mycode.MyClass.

Accessibility Modifiers?

Accessibility Modifiers play an important role in determining what assets can and cannot be imported. The following chart shows what can be imported from where: