Difference between revisions of "EiffelStudio Wish List"
(Wrong placement of Pro) |
m (Protected "EiffelStudio Wish List": We are moving the Wish list to a new site. ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))) |
||
(80 intermediate revisions by 12 users not shown) | |||
Line 1: | Line 1: | ||
− | [[Category: | + | [[Category:Projects]] |
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. | 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. | ||
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 | |
+ | || | ||
+ | * Would be a smart idea implementing this in a similar way as IP (Intentional Programming) does (storing source files as Abstract Syntax Tree, representable in different representations, and using a smart versioning system). More info: see [http://intentsoft.com/] | ||
|- | |- | ||
! Shared EIFGEN | ! Shared EIFGEN | ||
− | | Allow sharing of EIFGENs (in read-only mode)|| || || | + | | Allow sharing of EIFGENs (in read-only mode)|| || ||] |
+ | |||
+ | |||
+ | |- | ||
+ | ! On-demand tab loading | ||
+ | | Allow creation of an EV_NOTEBOOK tab with an agent to be called to fill the tab when it is first loaded|| || || | ||
+ | |||
|- | |- | ||
! Enum | ! 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". || || || | + | | 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". || || |
+ | * The best practice way to get a value that only needs to be defined once is by using the "once" keyword in combination with a feature. | ||
+ | || | ||
|- | |- | ||
Line 63: | Line 73: | ||
|- | |- | ||
! XXX | ! XXX | ||
− | | Ability for | + | | Ability for Eiffel Studio to cross compile || || || |
|- | |- | ||
Line 75: | Line 85: | ||
|- | |- | ||
! XXX | ! XXX | ||
− | | Ability for ANY to generate a unique id for each object for referencing and hashability || || || | + | | Ability for ANY to generate a unique id for each object for referencing and hashability || || |
+ | Objects that are hashable should implement HASHABLE | ||
+ | || | ||
|- | |- | ||
Line 88: | Line 100: | ||
! XXX | ! 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?). || || || | | 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?). || || || | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | ! Make `redefine' ECMA conform | ||
+ | | According ECMA 367 8.10.7 (Effect, effecting), | ||
+ | The `redefine' clause cannot be used to effect a inherited deferred feature. | ||
+ | This code should be rejected: | ||
+ | <e> | ||
+ | deferred class A feature | ||
+ | |||
+ | do_something | ||
+ | deferred end | ||
+ | |||
+ | end | ||
+ | |||
+ | class B inherit | ||
+ | A | ||
+ | redefine | ||
+ | do_something | ||
+ | end | ||
+ | |||
+ | feature | ||
+ | |||
+ | do_something | ||
+ | deferred end | ||
+ | |||
+ | end | ||
+ | </e> | ||
+ | || || || | ||
+ | |||
|} | |} | ||
Line 122: | Line 165: | ||
! XXX | ! XXX | ||
| An ability to call a parent .NET constructor from an Eiffel creation routine. || || || | | An ability to call a parent .NET constructor from an Eiffel creation routine. || || || | ||
+ | |||
|} | |} | ||
Line 128: | Line 172: | ||
{| class="wikitable" | {| class="wikitable" | ||
!ID !! Short Summary !! Pros !! Cons !! More info | !ID !! Short Summary !! Pros !! Cons !! More info | ||
+ | |||
+ | |- | ||
+ | ! XXX | ||
+ | | Halt repainting for the GUI library while the GUI is assembled or changed. | ||
+ | || || || | ||
|- | |- | ||
Line 220: | Line 269: | ||
! Improve search tool | ! 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. || || || | | 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. || || || | ||
+ | |||
+ | |- | ||
+ | ! Automatic source format | ||
+ | | There could be an option to tell the editor to reformat the code according to user preference settings. Those can address the multi-line expression format and the exceptions to the comb format (like for a class' name), for example. The reformat feature can be made to affect only the display so that different project members can view the source as it pleases them in an uniform way. || || || | ||
+ | |||
+ | |- | ||
+ | ! Customizing the font of different lexical components | ||
+ | | It would be useful to be able to set different fonts for different lexical components. It is already possible for keywords some other may be useful too like class names, locals, queries, commands, comments ... || || || | ||
+ | |||
+ | |- | ||
+ | !Auto Indent | ||
+ | |Auto indent does not work, yes it does what 90% of editors that clame to do auto indent do. But if you have seen auto indent you would know this is not it. | ||
+ | You should be able to just press <CR> at end of line and type. E.G. if you are in a do block and type ensure it should unindent. |Badly indented should be an earlt indication of some syntax errors. | ||
+ | | Less key presses, less stress. || || | ||
+ | |||
+ | |- | ||
+ | !Select and Paste | ||
+ | |Like On X, middle button pastes previus selection. | ||
+ | |less mouse presses || || | ||
+ | |||
+ | |- | ||
+ | !Dialog Boxes, Yes or No | ||
+ | |In a dialog box that askes whould you like to save, have buttons labelled "Save" and "Discard". | ||
+ | |||
+ | |Much quicker for intermediate and advanced users, as dont need to read all the text. Less error prone (as these users wont read the text) | ||
+ | |||
+ | Better for begginers: Resurch has shown that begginers see these questions as asking for permition, and do not feal qualified to give it. Most begginers press No the first time. Then later wonder where there work went. | ||
+ | |||
+ | Or even better just save it. | ||
+ | |||
+ | |See: "Open Office" for an example. | ||
+ | See: The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity (http://www.cooper.com/insights/books/) | ||
+ | |||
+ | || | ||
+ | |||
+ | |- | ||
+ | ! Pebble for Override Clusters | ||
+ | | Further integrate 'Override Clusters' into the IDE, i.e., rather than having to manually copy a class from an existing library to the override cluster's folder, use a pebble and drop the class in the override cluster directly. | ||
+ | || || || | ||
+ | |||
+ | |- | ||
+ | ! Explicit Types in interface view | ||
+ | | Replace the anchors with explicits types in interface view. It is easier to read. | ||
+ | | The developper does not limit his use of anchors because of readeability issues. | ||
+ | || || | ||
+ | |||
+ | |||
+ | |- | ||
+ | !Editing Text Files | ||
+ | |Being able to edit in the IDE other text files besides Eiffel class texts, for instance, gobo lex (.l) and yacc (.y), or C headers (.h). The files might be added manually to a cluster in the 'groups view'. | ||
+ | |||
+ | |More convenient than having to switch between the Eiffel IDE and another editor, for a task that is essentially the same (text editing). | ||
+ | |||
+ | | | ||
+ | || | ||
+ | |||
+ | | | ||
+ | |||
+ | |||
+ | |- | ||
+ | !Updated documentation checker | ||
+ | |Throw a warning if the documentation refers to a nonexistent feature. | ||
+ | For example: | ||
+ | <e> | ||
+ | apply | ||
+ | -- Call procedure with `args' as last set. | ||
+ | do | ||
+ | call (operands) | ||
+ | end | ||
+ | </e> | ||
+ | Throws a warning for nonexistent `args' feature. | ||
+ | This check could be a part of Inspector Eiffel. | ||
+ | |Help to maintain an updated documentation | ||
+ | | || || | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | !Improve code readability | ||
+ | |Use red color for dot (as assigment color) to make more readable a feature call in the editor view. | ||
+ | |||
+ | sometimes it is diffult to distinguish this two codes: | ||
+ | <e> | ||
+ | some_target.feature_of_some_type.feature_of_some_type_2 | ||
+ | </e> | ||
+ | |||
+ | <e> | ||
+ | some_target_feature_of_some_type.feature_of_some_type_2 | ||
+ | </e> | ||
+ | || || || | ||
|} | |} | ||
Line 230: | Line 369: | ||
! XXX | ! XXX | ||
| Allow to use '''?''' in assigner declaration For instance | | Allow to use '''?''' in assigner declaration For instance | ||
− | < | + | <e> |
− | foo: STRING assign set_key_value ("foo", ?) | + | foo: STRING assign set_key_value ("foo", ?) |
do | do | ||
Result := values.item ("foo") | Result := values.item ("foo") | ||
Line 238: | Line 377: | ||
values: HASH_TABLE [STRING, STRING] | values: HASH_TABLE [STRING, STRING] | ||
− | set_key_value (k | + | set_key_value (k, v: STRING) |
do | do | ||
− | values.force (v,k) | + | values.force (v, k) |
end | end | ||
− | </code> | + | </e> |
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | ! Convenient Number Syntax | ||
+ | || Adalike syntax for numbers, e.g. 2#101010 = 10#42 = 2#10_10_10 and 100_000_000 = 100000000. || effectively reduces silly bugs when reading and writing numbers || Eiffel allows underscores within numbers to allow digit grouping e.g. 8_961_226||see annotated ada reference manual || | ||
+ | |||
+ | |- | ||
+ | ! Exceptions mentioned in method interface | ||
+ | || syntax for telling developers about exceptions thrown by a method. e.g.: | ||
+ | <e> | ||
+ | foo( a : B): C | ||
+ | exceptions | ||
+ | Net_Unreachable, Net_Timeout | ||
+ | do | ||
+ | Result := values.item ("foo") | ||
+ | end | ||
+ | </e> | ||
+ | || Clear and elegant syntax, no more looking into the implementation to find out which exceptions might occur and which of them might be handled at which level. | ||
+ | || 1) new keyword. 2) new compiler option necessary (using this interface extension is fully useful only if enforced by the compiler which would break older code). 3) Does not scale well with sub classing and redefining features. Redefined versions may have fewer exceptions, in which some stated exceptions won't occur anymore, or more exceptions, where the feature would no longer conform to the signature and a hack would need to be made or redefining the base class in which case you have a fragile base class problem. The Eiffel way of handling exceptions with the paradigm "a feature either satisfies its contract or an exception is thrown" is really an elegant way of handling the unknown, although it takes some getting used to when coming from Java. ECMA exceptions as objects and the type multibranch instructions will help with non-trivial exception handling. | ||
+ | || | ||
+ | Could this be included only on generated views. Not in typed in code, as this can cause a maintinance problem having to propogate changes. | ||
+ | || | ||
+ | |||
+ | |- | ||
+ | ! 'across' with optional 'as' | ||
+ | | Allow to use '''across''' without '''as''' | ||
+ | <e> | ||
+ | a_routine | ||
+ | do | ||
+ | across 1 |..| 10 loop | ||
+ | -- do something | ||
+ | end | ||
+ | end | ||
+ | </e> | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | ! Simple conversion declaration | ||
+ | | Allow to write a simple conversion statment: | ||
+ | <e> | ||
+ | class | ||
+ | CONVERSION_PROPOSAL | ||
+ | |||
+ | create | ||
+ | make_from | ||
+ | |||
+ | convert | ||
+ | make_from, | ||
+ | something | ||
+ | |||
+ | feature | ||
+ | make_from (v: A_TYPE) | ||
+ | do end | ||
+ | |||
+ | something: ANOTHER_TYPE | ||
+ | do end | ||
+ | end | ||
+ | </e> | ||
+ | equivalent to: | ||
+ | <e> | ||
+ | class | ||
+ | CURRENT_CONVERSION | ||
+ | |||
+ | create | ||
+ | make_from | ||
+ | |||
+ | convert | ||
+ | make_from ({A_TYPE}), | ||
+ | something: {ANOTHER_TYPE} | ||
+ | |||
+ | feature | ||
+ | make_from (v: A_TYPE) | ||
+ | do end | ||
+ | |||
+ | something: ANOTHER_TYPE | ||
+ | do end | ||
+ | end | ||
+ | </e> | ||
+ | | Esaier and more readable declaration | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | ! Customized creation procedure for expanded type | ||
+ | | Allow to use another creation procedure. `default_create' is not longer required. | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |- | ||
+ | ! Remove 'only' postcondition | ||
+ | | Replace only postcondition with the old convention. | ||
+ | Bertrand MEYER described that in this article : [here][http://bertrandmeyer.com/2011/07/04/if-im-not-pure-at-least-my-functions-are/] | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | ! Explicit assigner command specification | ||
+ | | In the ECMA strandart (367), there is no information about renaming and exportation rules for assigner commands. | ||
+ | Proposition: | ||
+ | * Assigner Commands are not droped when the procedure is renamed or redefined. | ||
+ | * When a query is renamed the assigner may be changed. If there is no assigner command specified then it is removed. (similar to 'alias' behavior). | ||
+ | * Assigner command exportation is equivalent to the procedure. | ||
+ | |||
+ | However, if the exportation of the request is restricted then there is no sense to use the assigner command in the non-exported classes. | ||
+ | The previous rule could be replaced with : | ||
+ | * The assigner command is exported to the set of classes resulting of the intersection betwen the exported set of the request and of the command. | ||
+ | example: | ||
+ | <e> | ||
+ | class A feature {B, C} -- Access | ||
+ | q: A assign c | ||
+ | |||
+ | feature {C, D} -- Chnage | ||
+ | c (v: A) | ||
+ | do | ||
+ | q := v | ||
+ | end | ||
+ | end | ||
+ | </e> | ||
+ | <e> | ||
+ | -- o: A | ||
+ | o.q := v | ||
+ | </e> | ||
+ | is allowed in classes conforms to 'C'. | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |- | ||
+ | ! Enclosed alias | ||
+ | | Enclosed alias has similar behavior to bracket alias. | ||
+ | "[]", "<>", "{}" | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |- | ||
+ | ! Ensure a postcondition for assigner command | ||
+ | | After an assigment, the equality property is waited: | ||
+ | <e> | ||
+ | target := source | ||
+ | check target = source end | ||
+ | </e> | ||
+ | (Except for some cases such as NaN). | ||
+ | Therefore the postcondition of assigner commands should verify it. | ||
+ | <e> | ||
+ | class interface A feature | ||
+ | q (...): T assign c | ||
+ | |||
+ | c (a_q: T; ...) | ||
+ | ensure | ||
+ | q (...) = a_q | ||
+ | end | ||
+ | </e> | ||
+ | |||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |- | ||
+ | ! More strict semantic for `require else' and `ensure then' | ||
+ | | `require else' and `ensure then' cannot be used for the first declaration. | ||
+ | This code should be rejected: | ||
+ | <e> | ||
+ | class A feature | ||
+ | do_something | ||
+ | require else | ||
+ | True | ||
+ | do | ||
+ | ensure then | ||
+ | True | ||
+ | end | ||
+ | end | ||
+ | </e> | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |- | ||
+ | ! Conditional expression without `else' branch | ||
+ | | Allow a conditional expression without `else' branch. i.e. | ||
+ | <e> | ||
+ | if boolean_expression then expression end | ||
+ | </e> | ||
+ | is equivalent to: | ||
+ | <e> | ||
+ | if boolean_expression then expression else Void end | ||
+ | </e> | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |- | ||
+ | ! `note' clause and inheritance | ||
+ | | `note' clauses are inherited if they are not redefined. | ||
+ | |||
+ | e.g. | ||
+ | <e> | ||
+ | class A feature | ||
+ | something: ANY | ||
+ | note | ||
+ | what: "Documentation." | ||
+ | option: stable | ||
+ | do end | ||
+ | end | ||
+ | |||
+ | class B inherit A redefine something end feature | ||
+ | something: ANY | ||
+ | note | ||
+ | what: "New documentation." | ||
+ | do end | ||
+ | end | ||
+ | </e> | ||
+ | The `what' clause is not inheried since it is redefined. However the `option' clause is inherited. | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |- | ||
+ | ! Replace obsolete keyword with a simple note clause | ||
+ | | A note clause could replace the obsolete keyword | ||
+ | <e> | ||
+ | class A feature | ||
+ | something: ANY | ||
+ | note | ||
+ | obsolete: "Use another instead." | ||
+ | do end | ||
+ | end | ||
+ | </e> | ||
+ | instead of: | ||
+ | <e> | ||
+ | class A feature | ||
+ | something: ANY | ||
+ | obsolete | ||
+ | "Use another instead." | ||
+ | do end | ||
+ | end | ||
+ | </e> | ||
+ | |||
+ | | A keyword removed; simpler feature definition | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |||
+ | |} | ||
+ | |||
+ | == Library == | ||
+ | {| class="wikitable" | ||
+ | !ID !! Short Summary !! Pros !! Cons !! More info | ||
+ | |||
+ | |- | ||
+ | ! until_do_and_remove | ||
+ | | Add DISPENCER_ITERATOR[G->DISPENCER] inherit ITERATOR .... | ||
+ | Add procedures until_do_and_remove and its brothers. | ||
+ | | if I want to iterate a QUEUE, I dont want the items to exist afterwards. | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | ! SQL like where | ||
+ | | simmala to do_if, but a function: | ||
+ | <e> | ||
+ | where (test: PREDICATE [ANY, TUPLE [G]]): like Current | ||
+ | -- Items satisfying `test' | ||
+ | ... | ||
+ | </e> | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | ! slice functions | ||
+ | | | ||
+ | <e> | ||
+ | slice_until, slice_after, ... (test: PREDICATE [ANY, TUPLE [G]]): like Current | ||
+ | ... | ||
+ | </e> | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | ! Absolute query result as NATURAL | ||
+ | | Change the 'abs' request type. | ||
+ | <e> | ||
+ | abs: NATURAL_32 | ||
+ | -- (from INTEGER_32_REF) | ||
+ | ... | ||
+ | </e> | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |||
+ | |- | ||
+ | ! `factorial', `even', and `odd' queries | ||
+ | | Add features to NATURAL types. | ||
+ | <e> | ||
+ | factorial: like Current ... | ||
+ | |||
+ | even: BOOLEAN ... | ||
+ | |||
+ | odd: BOOLEAN ... | ||
+ | </e> | ||
| | | | ||
| | | | ||
Line 271: | Line 727: | ||
|- | |- | ||
! XXX | ! 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") || || || | + | | 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") || || |
+ | * Unused features are already eliminated in the dead code removal step when finalizing a system. | ||
+ | || | ||
|- | |- | ||
Line 279: | Line 737: | ||
|- | |- | ||
! Additional Classes | ! 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. || || || | + | | 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. || |
+ | |- | ||
+ | ! Easier Method for using eternal dll | ||
+ | | When I wanted to include the Advantage Database Server and Virtual Print Engine client libraries written in C with an Eiffel project I was told you had to write wrappers for the header files and create an Eiffel method for each of the function calls in the library. This was and is too time consuming. Eiffel should be able to use external dlls without all this work or it should generate the required classes/methods itself. As a result the project was completed in another language. | ||
+ | || || | ||
|} | |} |
Latest revision as of 08:22, 5 August 2015
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) | ]
| ||
On-demand tab loading | Allow creation of an EV_NOTEBOOK tab with an agent to be called to fill the tab when it is first loaded |
| ||
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 Eiffel Studio to cross compile | |||
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 |
Objects that are hashable should implement HASHABLE |
||
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?). |
| ||
Make `redefine' ECMA conform | According ECMA 367 8.10.7 (Effect, effecting),
The `redefine' clause cannot be used to effect a inherited deferred feature. This code should be rejected: deferred class A feature do_something deferred end end class B inherit A redefine do_something end feature do_something deferred end end |
|
.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 | Halt repainting for the GUI library while the GUI is assembled or changed. | ||||
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 [2]. 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. | ||||
Automatic source format | There could be an option to tell the editor to reformat the code according to user preference settings. Those can address the multi-line expression format and the exceptions to the comb format (like for a class' name), for example. The reformat feature can be made to affect only the display so that different project members can view the source as it pleases them in an uniform way. | ||||
Customizing the font of different lexical components | It would be useful to be able to set different fonts for different lexical components. It is already possible for keywords some other may be useful too like class names, locals, queries, commands, comments ... | ||||
Auto Indent | Auto indent does not work, yes it does what 90% of editors that clame to do auto indent do. But if you have seen auto indent you would know this is not it.
You should be able to just press <CR> at end of line and type. E.G. if you are in a do block and type ensure it should unindent. |Badly indented should be an earlt indication of some syntax errors. |
Less key presses, less stress. | |||
Select and Paste | Like On X, middle button pastes previus selection. | less mouse presses | |||
Dialog Boxes, Yes or No | In a dialog box that askes whould you like to save, have buttons labelled "Save" and "Discard". | Much quicker for intermediate and advanced users, as dont need to read all the text. Less error prone (as these users wont read the text)
Better for begginers: Resurch has shown that begginers see these questions as asking for permition, and do not feal qualified to give it. Most begginers press No the first time. Then later wonder where there work went. Or even better just save it. |
See: "Open Office" for an example.
See: The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity (http://www.cooper.com/insights/books/) |
||
Pebble for Override Clusters | Further integrate 'Override Clusters' into the IDE, i.e., rather than having to manually copy a class from an existing library to the override cluster's folder, use a pebble and drop the class in the override cluster directly. | ||||
Explicit Types in interface view | Replace the anchors with explicits types in interface view. It is easier to read. | The developper does not limit his use of anchors because of readeability issues. |
| ||
Editing Text Files | Being able to edit in the IDE other text files besides Eiffel class texts, for instance, gobo lex (.l) and yacc (.y), or C headers (.h). The files might be added manually to a cluster in the 'groups view'. | More convenient than having to switch between the Eiffel IDE and another editor, for a task that is essentially the same (text editing). |
| ||
Updated documentation checker | Throw a warning if the documentation refers to a nonexistent feature.
For example: apply -- Call procedure with `args' as last set. do call (operands) end Throws a warning for nonexistent `args' feature. This check could be a part of Inspector Eiffel. |
Help to maintain an updated documentation |
| ||
Improve code readability | Use red color for dot (as assigment color) to make more readable a feature call in the editor view.
sometimes it is diffult to distinguish this two codes: some_target.feature_of_some_type.feature_of_some_type_2 some_target_feature_of_some_type.feature_of_some_type_2
|
Language
ID | Short Summary | Pros | Cons | More info | |
---|---|---|---|---|---|
XXX | Allow to use ? in assigner declaration For instance
foo: STRING assign set_key_value ("foo", ?) do Result := values.item ("foo") end values: HASH_TABLE [STRING, STRING] set_key_value (k, v: STRING) do values.force (v, k) end |
||||
Convenient Number Syntax | Adalike syntax for numbers, e.g. 2#101010 = 10#42 = 2#10_10_10 and 100_000_000 = 100000000. | effectively reduces silly bugs when reading and writing numbers | Eiffel allows underscores within numbers to allow digit grouping e.g. 8_961_226 | see annotated ada reference manual | |
Exceptions mentioned in method interface | syntax for telling developers about exceptions thrown by a method. e.g.:
foo( a : B): C exceptions Net_Unreachable, Net_Timeout do Result := values.item ("foo") end |
Clear and elegant syntax, no more looking into the implementation to find out which exceptions might occur and which of them might be handled at which level. | 1) new keyword. 2) new compiler option necessary (using this interface extension is fully useful only if enforced by the compiler which would break older code). 3) Does not scale well with sub classing and redefining features. Redefined versions may have fewer exceptions, in which some stated exceptions won't occur anymore, or more exceptions, where the feature would no longer conform to the signature and a hack would need to be made or redefining the base class in which case you have a fragile base class problem. The Eiffel way of handling exceptions with the paradigm "a feature either satisfies its contract or an exception is thrown" is really an elegant way of handling the unknown, although it takes some getting used to when coming from Java. ECMA exceptions as objects and the type multibranch instructions will help with non-trivial exception handling. |
Could this be included only on generated views. Not in typed in code, as this can cause a maintinance problem having to propogate changes. |
|
'across' with optional 'as' | Allow to use across without as
a_routine do across 1 |..| 10 loop -- do something end end |
||||
Simple conversion declaration | Allow to write a simple conversion statment:
class CONVERSION_PROPOSAL create make_from convert make_from, something feature make_from (v: A_TYPE) do end something: ANOTHER_TYPE do end end equivalent to: class CURRENT_CONVERSION create make_from convert make_from ({A_TYPE}), something: {ANOTHER_TYPE} feature make_from (v: A_TYPE) do end something: ANOTHER_TYPE do end end |
Esaier and more readable declaration |
| ||
Customized creation procedure for expanded type | Allow to use another creation procedure. `default_create' is not longer required. |
| |||
Remove 'only' postcondition | Replace only postcondition with the old convention.
Bertrand MEYER described that in this article : [here][3] |
||||
Explicit assigner command specification | In the ECMA strandart (367), there is no information about renaming and exportation rules for assigner commands.
Proposition:
However, if the exportation of the request is restricted then there is no sense to use the assigner command in the non-exported classes. The previous rule could be replaced with :
example: class A feature {B, C} -- Access q: A assign c feature {C, D} -- Chnage c (v: A) do q := v end end -- o: A o.q := v is allowed in classes conforms to 'C'. |
| |||
Enclosed alias | Enclosed alias has similar behavior to bracket alias.
"[]", "<>", "{}" |
| |||
Ensure a postcondition for assigner command | After an assigment, the equality property is waited:
target := source check target = source end (Except for some cases such as NaN). Therefore the postcondition of assigner commands should verify it. class interface A feature q (...): T assign c c (a_q: T; ...) ensure q (...) = a_q end |
| |||
More strict semantic for `require else' and `ensure then' | `require else' and `ensure then' cannot be used for the first declaration.
This code should be rejected: class A feature do_something require else True do ensure then True end end |
| |||
Conditional expression without `else' branch | Allow a conditional expression without `else' branch. i.e.
if boolean_expression then expression end is equivalent to: if boolean_expression then expression else Void end |
| |||
`note' clause and inheritance | `note' clauses are inherited if they are not redefined.
e.g. class A feature something: ANY note what: "Documentation." option: stable do end end class B inherit A redefine something end feature something: ANY note what: "New documentation." do end end The `what' clause is not inheried since it is redefined. However the `option' clause is inherited. |
| |||
Replace obsolete keyword with a simple note clause | A note clause could replace the obsolete keyword
class A feature something: ANY note obsolete: "Use another instead." do end end instead of: class A feature something: ANY obsolete "Use another instead." do end end |
A keyword removed; simpler feature definition |
|
Library
ID | Short Summary | Pros | Cons | More info |
---|---|---|---|---|
until_do_and_remove | Add DISPENCER_ITERATOR[G->DISPENCER] inherit ITERATOR ....
Add procedures until_do_and_remove and its brothers. |
if I want to iterate a QUEUE, I dont want the items to exist afterwards. | ||
SQL like where | simmala to do_if, but a function:
where (test: PREDICATE [ANY, TUPLE [G]]): like Current -- Items satisfying `test' ... |
|||
slice functions |
slice_until, slice_after, ... (test: PREDICATE [ANY, TUPLE [G]]): like Current ... |
|||
Absolute query result as NATURAL | Change the 'abs' request type.
abs: NATURAL_32 -- (from INTEGER_32_REF) ... |
|||
`factorial', `even', and `odd' queries | Add features to NATURAL types.
factorial: like Current ... even: BOOLEAN ... odd: BOOLEAN ... |
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. | |||
Easier Method for using eternal dll | When I wanted to include the Advantage Database Server and Virtual Print Engine client libraries written in C with an Eiffel project I was told you had to write wrappers for the header files and create an Eiffel method for each of the function calls in the library. This was and is too time consuming. Eiffel should be able to use external dlls without all this work or it should generate the required classes/methods itself. As a result the project was completed in another language. |