eiffelroom - Comments

Ok, now I understand the

In reply to My three Eiffelwishes, part 3: readable types:

Ok, now I understand the reason to mark a query readable.

Saving the result of a query in a cache in order to avoid lengthy recalculations is not a real state change. I don't considers this as a violation of CQS. It could even be checked by the compiler. We could add a validity rule that a query can modify a private attribute only if the attribute is bound in the class invariant to be equal to the result of a query.

You're right that in almost

In reply to My three Eiffelwishes, part 3: readable types:

You're right that in almost every case a query doesn't change the state of the object. However, sometimes the query can take a long time to execute, and to make it faster the result can be saved in a cache.

So, in practice a query can modify an object, even though it will always return the same result.

If we want to enforce CQS on every program, then the readable mark becomes unnecessary. But CQS might not be the best way to implement a class every time. It's mentioned in http://en.wikipedia.org/wiki/Command-query_separation, although I don't find arguments compelling on either sides.

So I wanted to keep some freedom in deciding when an object state is really changing, and introduced the readable mark for features.

Your approach is very

In reply to My three Eiffelwishes, part 3: readable types:

Your approach is very interesting.

However I don't understand what it means to mark a feature which is already a query with `readable'. A query is already a query. A query should not change the state of any already existing object. I admit that this is not easy to check, because pure syntax analysis is not sufficient. But this is the common understanding of a query.

Exactly. I wanted to specify

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

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.

Specifying libraries

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

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.

I was not talking about

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

I was not talking about locations.

C# uses external files to

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

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.e. I can either write an

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

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

The way to use this is: ec

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

The way to use this is:

ec my_root_class.e

when you only need EiffelBase. Otherwise, to specify a library, you can do the following.

ec my_root_class.e -library $ISE_LIBRARY/library/vision2/vision2.ecf

That seems to be good. But

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

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?

Currently you can do `ec

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

Currently you can do `ec root_class.e' and it will compile the Eiffel class without having to provide an ECF.

On the topic of using Eiffel

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

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.

One-line Eiffel programs

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

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?

Can you give me a link to the

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

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

In reply to Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).:

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