Chapter 2. Creating Basic Modules

Creating a module is actually quite simple. At its base level, a module is really nothing more than a ferite script with a specific name that resides within ferite's module search path. By default, ferite will look for modules in the current directory and the system's ferite module directory (usually this is /usr/lib/ferite). The module must have a file extension of either .fe or .fec in order to be recognized by ferite. (.fec denotes a special kind of script that will be covered later)

So essentially any script that you write can be included as a module. A script can import modules and other scripts by using either the uses keyword, or the include() operation. When you import a module, you refer to it by it's filename, minus the .fe or .fec extension. So mymodule.fe would be imported by uses "mymodule";. Modules may also import other modules. If an application imports a module, which in turn imports other modules, then all of the functionality exposed by the implicitly imported modules will be available.

The following example shows a script importing a module and accessing an exposed function, and the module that is imported. They are in separate files residing in the same directory.

File 1 (the importer); Name: myscript

    uses "mymodule";
    
    foo.bar();
    		

File 2 (the module); Name: mymodule.fe

    uses "console";
    
    namespace foo{
    	function bar(){
    		Console.println("Hello there!");
    	}
    }
    		

Execution and result:

    $ ferite myscript
    Hello there!
    $
    		

In the previous example, the module had exposed a namespace (foo), and a function within that namespace (bar). However, this is not the limit of what can be exposed. Modules can expose functions, classes, namespaces, and global variables. Like regular scripts, modules can also modify existing namespaces and classes by using the modifies keyword.

There is nothing special that a module must do in order to expose functionality. When a module creates a namespace, it is automatically exposed. The same goes for classes, functions and global variables.

Something that should be noted, is that any code in the anonymous function of the module will be executed when the module is first imported. A module can be imported numerous times, but this will not cause the code to be executed more than once. You can safely put run-once initialization code in a module's anonymous function.

Here is an example of a module taking advantage of several abilities.

Name: myothermodule.fe

    uses "console";
    
    global {
    	number gMyNumber = 7;
    }
    
    class myclass{
    	string WhatISaid;
    
    	function myclass(string WhatToSay){
    		Console.println(WhatToSay);
    		self.WhatISaid = WhatToSay;
    	}
    	
    	function tryme(){
    		Console.println("You called myclass.tryme()!");
    		Console.println("When created, I said: " + self.WhatISaid);
    	}
    }
    
    namespace mynamespace{
    	function hellothere(){
    		Console.println("Hello there!");
    	}
    }
    
    function plainfunction(){
    	Console.println("You called plainfunction()!");
    }
    
    Console.println("I could be a module initializer!");
    		

This code would result in gMyNumber being exposed as a global variable. The class 'myclass' would be available, as well as all of it's class members. The namespace 'mynamespace' would also become available, and it would house a single function called hellothere(). You would also get a function called plainfunction() placed in the main namespace, accessible simply by it's name. And to top it off, upon the importing of the module, the Console.println statement would be executed. This is a very important feature to note, as it allows for module writers to place initialisation code that will be executed.