Difference between revisions of "EiffelStudio Wish List"
(Wrong placement of Pro) |
|||
| Line 19: | Line 19: | ||
* Much more appropriate to use a database to store relations (dependencies) between objects. | * Much more appropriate to use a database to store relations (dependencies) between objects. | ||
* Easier for using a shared repository amongst multiple users | * Easier for using a shared repository amongst multiple users | ||
| − | || || | + | || |
| + | * Sophisticated collaboration tools already exist for sharing project source e.g. SVN, CVS | ||
| + | || | ||
|- | |- | ||
Revision as of 09:20, 18 July 2007
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.
Contents
Compiler
General
| ID | Short Summary | Pros | Cons | More info |
|---|---|---|---|---|
| Source & Generated Files in an RDBMS and (optionally) Compile directly from database | Use an RDBMS to store all sources,libraries and generated files instead of a filesystem. Optionally directly compile from the database. Repository can be shared amongst multiple users | Pro's:
|
|
|
| Shared EIFGEN | Allow sharing of EIFGENs (in read-only mode) | |||
| Enum | 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". | |||
| Decimal | Addition of a decimal type / REAL_128 for 28 digit precision - | MA_DECIMAL is not efficient | MA_DECIMAL already covers this | |
| User types | I want to be able to define types .e.g. a decimal type as mentioned above. I know all built in types can be defined from scratch, except I a way to initialise from literals. So we need a way to define them as well. Suggest a new defered class with create methods from_literal( s:STRING), and queries is_interger_ok:BOOLIAN, is_real_ok:BOOLIAN, is_arbitary_string_ok:BOOLIAN, is_type_string_ok:BOOLIAN (we would define a new type of string just for this). The compiler when generating optimised code will have to compile the new types and dynamicaly bind to them to create an object that can be embeded into the code. I beleave this would let us write code like: x:DECIMAL; x=1.23 (without a conversion from REAL (float base2)) | |||
| CHARACTER_16 | CHARACTER_16 type | Smaller footprint than CHARACTER_32, UTF-16 is the default internal text representation for Windows/.Net/OS X/Java so conversion from CHARACTER_32 is costly, particular when dealing with large amounts of text | Please No! CHARACTER_32 covers this already. And UTF-8 is more space-efficient than UTF-16, which is an abomination. What will happen if you have a character from above the BMP? You will then have two CHARACTER_16s in the string for one real character - neither of which is a valid character - then `count' and `item' are all wrong. If you must have UTF-16 STRINGs, then let item return a CHARACTER_32. But note that having a UTF_16 STRING in itself won't eliminate all conversion costs - there is still the endian problem - this could be tackled by each individual UTF-16 STRING knowing whether it is UTF-16BE or UTF-16LE, but you may still need to convert. Comparing two such strings with different endianness would then have to be done using the codes - in what way is that going to be more efficient than using UTF-32? See Wish_CHARACTER_16 for more details on why it is not ok. | |
| 7-bit ASCII | 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) | |||
| MUTEX | Make MUTEX recursive on non-windows platforms or at least provide a mutex and separate recursive mutex for all platforms. | |||
| Multiple Precompiled. | Ability for multiple precompiles in a system. | |||
| XXX | Ability to compile/debug for both 32/64 bit systems via project settings | |||
| XXX | 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. | |||
| XXX | Ability for studio to work with binutils for cross compilation | |||
| XXX | 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 | |||
| XXX | 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 | |||
| XXX | Ability for ANY to generate a unique id for each object for referencing and hashability | |||
| XXX | 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). This may also require a reworking of the mismatch corrector facility as this does not appear to be thread-safe when magically called by the run-time | |||
| XXX | Ability for Studio to work and compile with Cygwin | |||
| XXX | 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?). |
.NET
| ID | Short Summary | Pros | Cons | More info |
|---|---|---|---|---|
| XXX | 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. |
|||
| XXX | Emit .NET generics types for Eiffel generic classes. | |||
| XXX | Allow direct access to member of TYPED_POINTER [xxx] item out/ref routine arguments. | |||
| XXX | Allow direct setting of TYPED_POINTER [xxx] item for out/ref routine arguments. | |||
| XXX | Optimized call.do_nothing as a IL pop instruction to removed returned value. | |||
| XXX | Custom attributes on routine arguments and Result. | |||
| XXX | An ability to call a parent .NET constructor from an Eiffel creation routine. |
IDE
| ID | Short Summary | Pros | Cons | More info |
|---|---|---|---|---|
| XXX | 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.) | |||
| XXX | 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. | |||
| XXX | Allow arguments and locals of a routine to be pickable so that they can be renamed via the refactoring tool. | In the case of arguments it might be interesting to allow
renaming in ancestor and descendant versions of the feature. | ||
| XXX | 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). | |||
| XXX | Make editor and grid more theme compliant in terms of color and font | |||
| XXX | 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. | To which other platform would it make porting easier? For the Mac OS port that's completely unnecessary I think. Also it would make the tree view look uglier (not as other tree views etc on the same platform) and inline editing can be made accessible in other ways (at least in OS X that's quite easy) | ||
| Extended Static Checking | Extended static checking integrated into the IDE. | Provides more immediate feedback on potential contract violations. | See, for example, ESC/Java2 and the associated Eclipse plugin, or Spec# integration into VisualStudio [1]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also ES-Verify | |
| XXX | Rearrange widgets of search tool so that they use free space on the right. Currently it uses too much vertical space. | I don't see free space on the right. Has this already been done? | ||
| XXX | Add an option to show the target name before the current edited class in the application title bar. When multiple projects are open, it's not possible to identify an EStudio session based on the title that appears on the tray bar | |||
| Step-by-step debugging | It would be useful in step-by-step debugging to be able to follow the execution cursor when checking the invariants as it is done for the preconditions and postconditions of a routine. This way, it would be easy to step into the right features and skip some (or all) of those present in the invariant. | |||
| Integrated Designer | It would be nice to have an integrated visual designer so that building business applications where visual design is very import can be created more easily. | |||
| Drag-n-Drop | Allow the alternative of using drag and drop everywhere instead of pick and drop. | |||
| Code annotation tags support | Log the tags contained in comments. For example, when using Eclipse, it is useful to leave TODO comments behind to ensure that a part that is not implemented will be eventually. When the time comes to clean up the TODO tags, a tool can list them all along with the descriptions and the locations of the comments. | Similar approach can be applied to indexing/note tags. | ||
| Token locations in flat-view | When debugging, I always look at flat view of a feature, then I found something that I want to change, so I have to go back to basic view. Buf often, I need to search the basic view to relocate the code. It would be nice if I can somehow pick a location in flat view and drop it into the right location in basic view. |
| ||
| External commands in context menu | Suppose there is an external command "tortoisediff $file_name" to show diff of a file from its working base, then when a context menu for a class is displayed, this command will be in it, and before launch this command, the $file_name placeholder will be replaced by the actual file name. Also, some special placeholders starting with # will be recognized. They represent open arguments. So before launching the command, a dialog will prompt out asking for those values. | Easy to use, no need to go to Console tool anymore. | ||
| Outline | When a mouse pointer is over a class name, a feature name, etc., it would be nice to see in a pop-up tooltip some basic information about it like description, header comment, signature, etc. | |||
| Current value of a variable | When a mouse pointer is over a variable in debug mode if would be nice to see in a pop-up tooltip its value. | |||
| Immediate syntax checks | It would be nice if editor can detect syntax errors and warnings and highlight them inline as well as outline (using a vertical bar, an icon of a particular color, etc.). | Syntax warnings include obsolete language constructs as well as unused code (such as unused local variables). For them it should be possible to suggest a replacement, so that manual editing is not required. | ||
| Refactoring: unused inheritance | A new tool can be introduced to check if a given inheritance path is actually used in a project and if not, would suggest to remove it. | It would be great to be able to run such tools in background, so that the checks are invisible to the user that only gets a warning and a suggestion to remove the unused parent clause. This way some other similar tools can be added. | ||
| Refactoring: unused arguments | A new tool can be introduced to check if all arguments of a feature are used (including all versions of the feature) and would suggest to remove those that are never used. | |||
| Refactoring: more interactive renaming | Renaming tool can be changed to prompt for renaming in comments and strings (one by one) rather than to apply renaming for all of them silently. | |||
| Improve search tool | Progress of search operation could be shown when performing search on a project and would ensure that the IDE remains responsible at that time. It should be also possible for a user to break the search operation. |
Language
| ID | Short Summary | Pros | Cons | More info |
|---|---|---|---|---|
| XXX | Allow to use ? in assigner declaration For instance
foo: STRING assign set_key_value ("foo", ?) is do Result := values.item ("foo") end values: HASH_TABLE [STRING, STRING] set_key_value (k: STRING; v: STRING) is do values.force (v,k) end |
Other
| ID | Short Summary | Pros | Cons | More info |
|---|---|---|---|---|
| XXX | Make every effective EiffelBase class implement default_create so that it can be used to instantiate any class with default values. |
| ||
| XXX | Provide a WEAK_REFERENCE [G] class to abstract away the implementation details currently provided by IDENTIFIED for implementing weak references. | |||
| XXX | Locale support to determine what the default charset is (or whether it is UTF-8 or not) | |||
| XXX | Build an object storing database with built-in record locking so that multiple systems can have access to the same 'objects' | |||
| XXX | 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") | |||
| XXX | 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. | |||
| Additional Classes | It would be nice to have classes in the basic eiffel libraries for handling serial port communication, zip compression, encryption, smtp, pop3, ftp, http, TCP/IP, usb, pdf generation, print engine for report writing. I am sure their are others but the basic idea is that it would be nice to have a complete multi-OS tool for developing business applications with quick access to classes needed. Presently you have to search the internet to find some of these classes. It would be nicer to have a more complete library available from within the IDE. |
