EiffelStudio Wish List

Revision as of 03:25, 30 November 2006 by Paco (Talk | contribs) (General)

Welcome to the Eiffel/EiffelStudio Wish List. This is the place where you, the community, get a chance to tell us what you think is important to include in the future versions of the Eiffel compiler and EiffelStudio IDE.

Please use this list responsibly and try to correctly categorize your wishes. A brief description may help us evaluate your requirements but please be brief.

Our stock pile of genie snared, dusty gold lamps is running low for our next release (EiffelStudio Releases) but we'll be sure to scour the lands for more.



  • A way to author Enum-like class for typed options or flags. Currently using INTEGER and a bag of analogous constants doesn't make Eiffel "elegant".
  • Addition of a decimal type / REAL_128 for 28 digit precision - ALREADY EXISTS - class MA_DECIMAL in the Gobo libraries is shipped with the compiler.
  • CHARACTER_16 type - Please NO! CHARACTER_32 covers this already.
  • 7-bit (US) ASCII_CHARACTER and ASCII_STRING which extends upon an ARRAY [ASCII_CHARACTER] with values of 0-127, removing the need for UTF8 conversion/checking when passing basic char values to C (gtk interfacing for example when connecting to signals)
  • Make MUTEX recursive on non-windows platforms or at least provide a mutex and separate recursive mutex for all platforms.
  • Ability for multiple precompiles in a system.
  • Ability to compile/debug for both 32/64 bit systems via project settings
  • Ability for for a fully optimal finalization for systems marked as 'client only', so that unused variables will not get generated in the finalized C Code.
  • Ability for studio to work with binutils for cross compilation
  • Ability to be able to control all user settable options in studio without having to resort to manually editing files, this is mainly for C compilation options
  • Have a smarter C code generation system that can launch a C compilation of any module as soon as the C code is generated, this way we can also be smarter when monitoring C compilation progress
  • Ability for ANY to generate a unique id for each object for referencing and hashability
  • With hashable ability of ANY, change object graph traversal for serialization so that multiple threads can serialize at the same time without having to wait linearly (lock_marking/unlock_marking)
  • Ability for Studio to work and compile with Cygwin
  • Ability to get a list of file dependencies in the form of a file listing to stdout. This list would contain a) all .e files used in the system, b) all .lib/.so files explicitly listed in the ECF/Ace file and c) all .h files referenced in external features (ideally that have not been subjected to dead code removal). Preferably, this feature should be able to be used without performing a full compilation (level 4?).


  • Consume .NET generics. Not being able to use them is becoming harder.
    We cannot write Atlas (AJAX) based web applications because of it. The Visual Studio SDK, used by EiffelEnvision, is increasing it's use of generics and preventing use from supporting some features. The people who want to use the .NET framework classes instead of the Eiffel ones cannot use generics and have to resort to using the non-generic versions of list, which bulks implementation and leads ambiguity.
  • Emit .NET generics types for Eiffel generic classes.
  • Allow direct access to member of TYPED_POINTER [xxx] item out/ref routine arguments.
  • Allow direct setting of TYPED_POINTER [xxx] item for out/ref routine arguments.
  • Optimized call.do_nothing as a IL pop instruction to removed returned value.


  • Give the user control over which classes will be compiled over the GUI (say: click on grey class and it becomes yellow and will be compiled always from now on, even though it may not be used at all. This is good for development of classes which are not added over GUI in ES.)
  • While searching for word or after a double click on a word, it would be nice if all words would be highlighted in pastel color style.
  • It's a pain to pick`n`drop huge features source code into the context window for setting break point. What about the following: Pick on the right side of the class text picks the feature as well? (Pick on the left side of the class text picks already the feature call).
  • Make editor and grid more theme compliant in terms of color and font
  • Remove all use of EV_TREE and EV_MULTI_COLUMN_LIST from studio so that all list widgets are drawn by vision2, this will make porting easier, we can also use the grid items to be able to change names of clusters, classes and features inline via the tree items.
  • Extended static checking integrated into the IDE.
  • Rearrange widgets of search tool so that they use free space on the right. Currently it uses too much vertical space.


  • Provide a WEAK_REFERENCE [G] class to abstract away the implementation details currently provided by IDENTIFIED for implementing weak references.
  • Locale support to determine what the default charset is (or whether it is UTF-8 or not)
  • Build an object storing database with built-in record locking so that multiple systems can have access to the same 'objects'
  • Make base.ecf rely on smaller ecf's (kernel.ecf, structures.ecf, support.ecf) so that these smaller dependancies can be compiled in only if needs be. It would be good if ANY could be optimized so that it doesn't have any references to io (or print) or mismatch information (only needed when storable is employed) as these bring in a lot of overhead when compiling a simple system. The smaller ecf could also link in with the object files of the runtime to avoid linking against a monolithic runtime (cecil, storable, etc) when you only want to print ("Hello World")
  • Put more of the run-time code in to inline C code reducing the size of the executable if you are not using certain features, ideally the linked against runtime should only contain the core functionality needed to create objects, perform simple operations and garbage collect, any other features can be brought in on a class/library/configuration level.