SourceForge.net LogoThe Eiffel Compiler / Interpreter (tecomp)

doc/papers/lang/cluster

Cluster concept (namespaces)

Introduction

The Eiffel language in its current definition has no concept of namespaces. However in large programs using many libraries name clashes (i.e. two classes having the same name) become more and more probable.

Different Eiffel compilers have resolved the name clashes with different strategies. This is not satisfactory because it is not portable. Therefore the Eiffel language should be extended to resolve potential name clashes of class names in a manner which is independent of the used compiler.

The following paper contains a proposal for a cluster concept which is capable of handling and resolving class name clashes. All the mechanisms described below are extensions to the Eiffel language. I.e. with that extensions the Eiffel language is capable of handling and resolving name clashes within the language (without the use of some compiler specific configuration files).

The basic concepts are views and clusters. Each class belongs to exactly one cluster and has exactly a view of classes which it can use. This makes it possible that a class does not see all classes of the universe but only a limited set of classes. Furthermore views have the possibility to rename some of the classes. A class rename is local to a view.

Fully qualified names for classes are introduced as a last resort to resolve name clashes.

Having a standardized way to express used clusters within Eiffel, it is possible to simplify small programs as a side effect. Complete Eiffel programs can be contained within one file with all the needed (usually very little to none) cluster information. A "Hello world" program becomes the trivial do print("Hello world%N") end without any definition of a root class nor a root procedure and without any necessary configuration file.

Therefore the cluster concept makes Eiffel more scalable in both directions: for small programs and for large programs.

Clusters

A cluster is a set of classes. Clusters are represented in a file system as a directory with all its subdirectories recursively. Each Eiffel file `some_name.e' within a cluster contains exactly one class with the name SOME_NAME. Only if an Eiffel file is a main file, it can contain several eiffel classes (see below for Eiffel main files).

    Cluster name rule: A cluster including all its subclusters must not
    contain duplicate class names nor duplicate file names (VCNR)
    Cluster no overlap rule: A class is contained in exactly one
    cluster. Clusters must not overlap, i.e. a subcluster of a cluster cannot
    be considered as an own cluster (VCNO).

An Eiffel compiler searches for needed clusters in the following order

  1. The directory of the main file.
  2. All paths given on the command line as "-Ipath_1 -Ipath_2" in the order given.
  3. All paths of the environment variable EIFFEL_CLUSTER_PATH (separated by `:')
  4. The standard library path compiled into the Eiffel compiler (usually /usr/local/lib/eiffel).

Usually application clusters (including application libraries) are located in the directory of the main file and standard libraries are located in the standard library path. Therefore in most of the cases command line include paths and paths within the environment variable EIFFEL_CLUSTER_PATH are not necessary.

Eiffel units

An Eiffel unit is either a program or a library. A unit can be compiled and validated separately.

A complete Eiffel program needs a mainfile which is either an *.ace file or an *.e file.

Eiffel program with a *.e file

The simplest Eiffel program:

   -- content of the file "hello.e"
   do
     print("Hello world%N")
   end
 

The Eiffel compiler converts that implicitely to

   -- ace section
   default
       assertion(all)
   cluster
       "eiffel/lang"
   end
 
   -- root class
   class 
        ROOT_CLASSS 
   create 
        make 
   feature 
        make 
          do 
             print("Hello world.%N") 
          end
   end
 

Every Eiffel program uses the cluster "eiffel/lang" either explicitely or implicitely. If nothing is specified, assertion monitoring is on.

The grammar of a main *.e file of an Eiffel program looks like

  Main_eiffel_file:
      [Ace_section]
      {Class_in_main_file ...}+
  Class_in_main_file:
      Class_declaration | Root_class    -- There must be exactly one root
                                        -- class within a main file
  Root_class:
      [Feature_block] do Compound end

All the classes within the main Eiffel file form a cluster called the main cluster.

An Eiffel program can use other clusters. All the used clusters except "eiffel/lang" must be specified in the cluster part of the ace section

   cluster
      cluster_1
      cluster_2
   end
 

Eiffel program with an *.ace file

An Eiffel program can be specified with an ace file as well. Example of an ace file:

   -- content of the file "my_program.ace"
   {ROOT_CLASS}.make
 
   default
      assertion(no)
   cluster
      "my/cluster_1"
      "my/cluster_2"
         option
            assertion(all): ASS_CLASS_1, ASS_CLASS_2
         end
      "eiffel/container"
      ...
   end
 
   Root class rule: The root class must be contained in exactly one of the
   used clusters (VCRC).

An Eiffel program specified with an ace file as mainfile does not have a main cluster.

Eiffel libraries

An Eiffel library is an Eiffel cluster on the file system which has an own ace file named lib.ace.

   Eiffel library rule: The ace file of a library must not contain a root
   class. All the clusters used by a library must be libraries as well (VCEL).

Views

With the above definitions it is assured that every Eiffel class of an Eiffel program or an Eiffel library belongs to exactly one cluster. Within the cluster there are no class name ambiguities.

If the cluster of a class is a library, the class belongs to that library. If the class does not belong to a library it belongs to the program.

Each Eiffel library and Eiffel program have a view. The view of a program consists of all Eiffel classes in the main cluster and its used clusters. The view of a library consists of all Eiffel classes within its cluster and all used clusters. A view might contain duplicate class names.

Each class has a view which is identical to the view of the unit (either the program or a library) to which it belongs.

   Class view rule: A class C can use another class A directly only if A is in
   its view (VCCV).

The class view rule already rules out many ambiguities. In many cases even big programs can be structured with a set of application libraries which have restricted views in order to rule out ambiguities. However some ambiguities might remain.

Remaining ambiguities can be resolved by various strategies:

  1. A class within the same cluster takes precedence over a class within a used cluster.
  2. Fully qualified names can be used to specify a class uniquely (e.g. eiffel.container.ARRAYED_SEQUENCE, my.cluster_1.MY_CLASS, ...).
  3. A view can rename classes of used clusters. The rename is valid only in the specific view.

Remember that a view is constituted by an ace section. An ace section can mention various used clusters. Each cluster can have a rename clause

   cluster
       "my/cluster_1"
           rename 
              BUTTON as BUTTON_1
           end
       "my/cluster_2"
           rename 
              BUTTON as BUTTON_2
           end
   end
 
   Class name rule: A class can use other classes directly by name only if the
   name is unique within its view or there is a class with that name within
   its cluster. All ambiguites must be resolved by using fully qualified class
   names or by rename (VCUN).

Export restrictions

Export restrictions can be used to shrink views and therefore to reduce the probability of class name clashes. A library (i.e. a cluster with its own ace file lib.ace) can define some of its subclusters private.

   -- contents of a file "lib.ace"
   export {NONE}
      "sub/cluster_1"
      "sub/cluster_2"
      ...
   cluster
      "used/library_1"
      "used/library_2"
      ....
   end
 

In the above example the library declares its subclusters "sub/cluster_1" and "sub/cluster_2" as private. Every program or library which includes this library in its cluster set won't have the classes of the private subclusters in its view.

Export restrictions only make sense in libraries. An export restriction in an ace file of a program is possible but meaningless.

Discussion

Feel free to comment on that topic at http://sourceforge.net/projects/tecomp/forums/forum/1034481.

 Local Variables: 
 mode: outline
 coding: iso-latin-1
 outline-regexp: "=\\(=\\)*"
 End:
Table of contents

- Introduction

- Clusters

- Eiffel units

- Eiffel program with a *.e file

- Eiffel program with an *.ace file

- Eiffel libraries

- Views

- Export restrictions

- Discussion


ip-location