Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).
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 independant from 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.
Read the detailed paper at http://tecomp.sourceforge.net/index.php?file=doc/papers/lang/cluster.txt
Have you looked at the way it is done in EiffelStudio, it seems you a re describing exactly all the features we are supporting. If not then, could you provide what are the differences?
Can you give me a link to the documentation of how it is done in Eiffelstudio. I have searched but not found.
But as far as I know, Eiffelstudio does not have a cluster concept within the language. It relies on xml files to describe the cluster structure (it is like C/C++ relying on makefiles). I would prefer to have it in the language (like java, scala, etc.).
Currently the language specification does not allow for restricted visibility (neither ECMA, nor OOSC, nor ETL2). The ECMA standard talks about a universe and that all classes in the universe must have unique names.
The goal of my proposal is to include the visibility etc. into the language (therefore I have proposed validity codes as well).
- Is the ability to create one-line Eiffel programs compelling?
- Do existing project generators make it easy enough to create new programs?
- If the issue is non-portability, why would another standard solve the issue?
- Is portability between Eiffel compilers compelling?
- Is class naming between different software units really the biggest issue of portability? As far as I can see the existing Eiffel compilers implement the language to varying degrees. Most diverge from the ECMA standard, the only language specification actually submitted to any standards organization.
- Allowing multiple class definitions in a single file but only the main file doesn't seem compelling.
- Using search paths with first-occurrence resolution seems like a step backwards.
One-line Eiffel programs
The ability to create one-line Eiffel programs would be compelling to newcomers. The lower the barrier to entry, the more people will come in and take a look.
So that's the marketing reason.
On the more practical side, if this capability existed then it might open up new ways of using Eiffel in contexts where we would normally think of using scripting languages. I'm not sure what, but is it worth considering?
On the topic of using Eiffel to perform tasks usually done in scripting languages, I thought it would be a good project to create a utility class that performed operating system maintenance tasks, things usually done by scripting languages e.g. making a class that has features with similar names to bash script commands.
Currently you can do `ec root_class.e' and it will compile the Eiffel class without having to provide an ECF.
That seems to be good. But where is the information which is usually written in the ecf. The file `root_class.e' might want to use libraries.
Can you give me a link to the documentation?
The way to use this is:
ec
The way to use this is:
when you only need EiffelBase. Otherwise, to specify a library, you can do the following.
i.e. I can either write an ecf file or specify some of the contents of an ecf file on the command line.
I assume all that is EiffelStudio specific.
I would like to advertise the idea to include some of that into the language like other modern languages (e.g. scala, java and C#) do it as well (e.g. packages).
C# uses external files to define references, the .csproj files.
Almost all build systems of any size use some sort of build script to define the location of references.
The environment variable idea seems to work on small projects until the need to build multiple branches of code on the same machine arises. Then people leave the environment variables empty and create build scripts to set environment variables right before invoking the compiler.
C#/Java use import/using directives to resolve namespaces. It doesn't relate to assembly/jar/classfile location.
I was not talking about locations.
Specifying libraries
Sure. Helmut, you weren't talking about specifying the locations of libraries, you were talking about specifying which libraries to use, if I understood you.
Colin pointed out (if I understood him, though I think he confused matters by mentioning the word "location") that in C# you don't specify which libraries you want to use in your C# source files. You specify the libraries in your project files (.csproj). I think you can also do it on the command line in C#, though I don't think I've ever tried it. But you certainly don't specify library dependencies in the C# source code.
Exactly. I wanted to specify which libraries to use within the language. The locations (a search path for libraries) can be specified outside.
I am not very familiar with C#. I am obviously wrong with regard to C# (however: doesn't C# have qualified classnames?). I am more familiar with java and scala. They have a package concept which is very similar to Eiffel's cluster concept. In scala and java the packages are specified within the language.
In my opinion Bertrand's original lace concept is the right way to go. However the original lace concept is too overloaded with details which should not be part of the language. I consider my proposal as a simplified version of lace which can be integrated within the Eiffel language in order to have one language "Eiffel" and not two languages "Eiffel" and "lace". In my opinion the resolution of class name clashes (i.e. scalability of Eiffel for large systems) should not be buried within some obscure xml files.