Index of Content
  1. Basic concepts
  2. Introduction to modifiers
  3. Basic Classes
  4. Errors and Exceptions
  5. Caching
  6. Caching on Mutable objects
  7. Interfaces and Matching
  8. Collections and Sequences
  9. Input Output
  10. Exercises
  11. Metaprogramming Introduction
  12. Programmatic Refactoring
  13. More Decorators
  14. Example of a 42 Program
  15. Deploy code

      Previous ... Next

Deploy 42

In the context of 42 and AdamsTowel, there are three things that can be deployed: Executable programs, Towels and Modules.

(1/5)Deploy Towels

A towel is about the most massively useful thing a programmer can have. A towel has immense psychological value, and you should always know where your towel is. All the classes that we have used up to now without defining them, are defined in AdamsTowel. They are all normal classes/libraries.
You can code without a towel, but this means starting from first principles, which could be quite unpleasant; especially since the only primitive things that 42 offers are Library literals (code as first class entities), the constant «», and the types «», «» and «».

Towels are libraries providing standard functionalities and types, such as number, boolean, string and various kinds of decorators and system errors.

However, we do not expect all 42 programs to reuse the same exact towel. For hygienic reasons, in real life everyone tends to use their own towel. For similar reasons, any sizeable 42 program will use its own towel.

We expect different programs to use massively different libraries for what in other languages is the standard library. That is, there is no such thing as 'the 42 standard library'.

Using multiple Towels

Towels shines when multiple towels are used at the same time.

Different code parts build upon different set of classes. That is, by introducing multiple towels in nested scopes, the names of the other scopes are masked. This is very useful for code that reasons on code; such task is pervasive in 42.

Staining Towels

If you are writing a sizeable program, or many similar programs, it make sense to enrich a towel with some pre loaded libraries and basic classes.

If you have write access to a github project under «», the former code will create your towel and update it on your github repository every time you run it. If you want to just write on your hard drive, you could just do
We are considering adding more variants, for example to allow writing on your FTP servers, google drives, dropbox and other similar services.

A Stained Towel is a towel that looks like another but it is enriched by adding more things, either at the bottom. In our example, «» is just a stained variation of «».

(2/5)Module deployment

If you start writing in 42, you will soon feel the need to factorize your project into libraries that can be independently tested, deployed and loaded. We call those library Modules. Very successful modules are used by multiple independent projects and developers; they are what is often called a third party library. However, most modules exists just as development tools in order to keep the complexity of big projects under control.

In 42 it is easy to code with multiple modules, and modules can be much smaller than usual third party libraries and frameworks in other languages.

In 42 it is possible to employ a programming model where every developer (or every pair of developers in a pair programming style) is the only one responsible of one (or more) modules and their maintenance process, while the group leader gives specifications and tests to be met by the various module developers and will glue all the code together.

Modules can be deployed in a way similar to towel deployment; «» is used to load libraries, but it also contains all the knowledge to deploy them.
The following example code deploys a Module using «»:

This code deploys «» to an URL as a module, and turns «» and any other nested classes stained on top of «» private. This includes «», «» and «» from «».
If there were any nested classes unreachable from public classes inside «» it will be pruned away. Same for any nested class stained on top of «» and for any private unreachable one in «».

The deployed library can be imported as usual. For example the main «» allows us to see the content of «».

All the deployed code is closed code. Towels are closed because they contain all the code to implement strings, numbers and so on. Modules are also closed. They have abstract classes/methods for each of the original towel concepts (before staining), and they can be rebound to a multitude of towels. In particular all stained versions of the same towel are compatible. Every needed nested library that was not present in the original towel, will be made private. On the other side, all the classes in the original towel will be made abstract by «» and will be rebound to the current towel by «».

Thus, in our example, «», «», «» and «» would become a private implementation detail of the exposed library.

(3/5)Deploy programs

We can run our applications inside 42, but we can also deploy them as Jars, so that they can be run as a Java application.
In 42 libraries can be directly manipulated, and one possible manipulation is to convert them in another format, like an executable jar or a native program and then save the result somewhere, such as on the website where the users can download it.
For example, we could rework the code of the former chapter as follows: 

>model )
    )
  }
//..
Tast = DeployGit.jar(ToJar()
  on=Url"github.com/Bob/Modules42/MyApplication.jar"
  writer=GW.#$of(token=Secret.#$of(),message=S".."))
]]>
As you can see, we are wrapping the application code into a trait, including a second reuse of «». In this way the code of «» is fully self contained, and «» in the outer scope can still use all of the towel features by taking them from the outer «». We then use «» to deploy our application onto a jar in a specific location. Again, we could just deploy it on our file system or on another kind of service by using another kind of «».

When 42 is used to deploy an application as a Jar, you can see the whole 42 execution as a comprehensive compilation framework, encompassing all the tools and phases that could possibly be needed into a single cohesive abstraction. Such jar can be run with the following command «»

In this example we reuse AdamsTowel both outside «» and inside of it. The two towels do not need to be the same. The outermost just has to support the deployment process «», while the inner one is needed to make «» a closed library: only libraries that do not refer to external classes can be deployed.

A 42 project testing and deploying

A common way to use 42 is to have a folder with the name of your project, containing a folder «» with all the actual code, and then various files providing testing and deploying functionalities, as in the following example:

In general, for medium size projects is a good idea to keep executing the tests before the deployment; for example we can have a test suite after the «». Do not panic, If the test are not reachable from «», they are not going to be included in the executable jar.

(4/5)Towel embroidery: Define and deploy our own towel

Towel embroidery it is like adding your initials to your towel.

While we can simply add to the end by staining, embroidery is much more powerful.

The most common embroidery tool is «». Together with late casts, we can add methods to any existing class as shown below:

The advantage with respect to composing two separated libraries is that the scope is the same: the implementation of «» will be able to use «», «» and so on. Towel staining is a very minimal personalization, and stained towels are fully compatible with the original one. With embroidery you can personalize the content of your towel a lot more, but when module deployment relies on an embroidered towel, compatibility with the original towel is lost. For example, an embroidered version of «» can «» a library developed on the original «», but a library developed on the embroidered version needs to be loaded into a similarly embroidered towel. One typical reason to embroider a towel is to extend the set of classes that are shared between libraries. For example, one may want to develop a Towel for scientific use where the existence of some units of measure can be shared between all the libraries. We could do the following: 
Num]:{@AbstractTowel{
    "en.wikipedia.org/wiki/International_System_of_Units"}}
  Load$={
    class method Introspection.Nested.List _baseDeps()
    class method Introspection.Nested.List baseDeps() = this._baseDeps().withAlso(\[
      Info(Unit);
      Info(SI);
      ])      
    }
  }
Secret = {...}
GW = Load:{reuse [L42.is/GitWriter]}
LoadDeploy = Load:{reuse [L42.is/Deploy]}
DeployGit = LoadDeploy.with(writer=GW)
DeployRicherTowel = DeployGit.towel(
  Organize:RawCode
    ['Load.baseDeps()->'Load._baseDeps()]
    [hide='Load._baseDeps()]
  on=Url"github.com/Bob/Modules42/SITowel.L42"
  writer=GW.#$of(token=Secret.#$of(),message=S".."))
]]>
Now «» can be used as a towel, and can be used to deploy modules that can be loaded by «».

By using semantic URIs as ontological nodes, we can create a basis for other libraries when trying to infer the meaning of our added types. In the example above we used wikipedia links to relevant concepts. This may not be the best solution, devising a good solution for this problem would require very intense research in the area of Ontological mapping.

«» can be used now to deploy and load libraries wrote in «», and libraries deployed and loaded in this way will share a unique definition for certain units of measure. Note that libraries originally developed for «» can still be loaded normally since «» is structurally a superset of «».

(5/5)Deployment: programs, libraries and towels; summary

  • 42 is a metaprogramming tool. It is natural to use 42 either as a language (to run a program) or as a compiler (to deploy programs, libraries and towels).
  • Indeed we expect all sizeable 42 projects to use 42 as a compiler, to produce some reusable artefacts.
  • The distinction between towels (that do not need «») and modules is introduced not by 42, but by «»; radically different towels may provide different meaning for the concepts of deploying and loading libraries/towels.
  • Application developers can freely stain and embroider towels; in this way they can adapt «» to serve them better. However, library developers need to carefully consider the effect of embroidery.

      Previous ... Next