| 28 |   | Bla bla bla ... | 
                      
                      
                        |   | 28 | The idea of a package comes from the concept of modularity and the possibility of loading and | 
                      
                        |   | 29 | distributing a whole module as a unit. A TOL package is essentially no more than a NameBlock | 
                      
                        |   | 30 | distributed in an .oza file.  | 
                      
                        |   | 31 |  | 
                      
                        |   | 32 | In the TOL programming frame, we identify the package with the NameBlock that contains | 
                      
                        |   | 33 | the set of classes, structurs, variables, functions and definitions. This is distributed and loaded as | 
                      
                        |   | 34 | an unit of the TOL package system. | 
                      
                        |   | 35 |  | 
                      
                        |   | 36 | Looking more from a distribution-focused point of view, a package is a compressed file | 
                      
                        |   | 37 | (specifically a .zip file) that contains the nameblock serialisation (an .oza file). This is | 
                      
                        |   | 38 | accompanied by other complementary resources that can be: files containing icons or images, | 
                      
                        |   | 39 | documentation, libraries of compiled functions (written in C++ and distributed in .dll or .so files) | 
                      
                        |   | 40 | and even uncompiled TOL code ( .tol files) by way of example. | 
                      
                        |   | 41 |  | 
                      
                        |   | 42 | == Names and versions == | 
                      
                        |   | 43 |  | 
                      
                        |   | 44 | A TOL package is identifed by its name and version. | 
                      
                        |   | 45 |  | 
                      
                        |   | 46 | The name of the package matches with the name of the nameblock that represents it. It generally | 
                      
                        |   | 47 | follows a CamelCase structure. | 
                      
                        |   | 48 |  | 
                      
                        |   | 49 | The version consists of integers. The first (the high version number) shows if there has been an | 
                      
                        |   | 50 | important change in the structure and functionality; one which could break the compatability | 
                      
                        |   | 51 | with the user-code in use. The second however (the low version number) shows that changes | 
                      
                        |   | 52 | have been made to the package that maintain package-use compatibility. These changes could | 
                      
                        |   | 53 | be corrections or the inclusion of new functionalities. | 
                      
                        |   | 54 |  | 
                      
                        |   | 55 | The package identifier is created by linking the name and two version numbers | 
                      
                        |   | 56 | <name>.<version.high>.<version.low> with a full-stop (.). | 
                      
                        |   | 57 | For example, the identifier {{{GuiTools.3.5}}} makes reference to version 3.5 of GuiTools, which | 
                      
                        |   | 58 | includes utilities for TOLBase graphical integration. |