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.

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).

- 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.

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.

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.

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.