Difference between revisions of "EiffelStudio Wish List"

m (Customized creation procedure for expanded type)
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)))
 
(45 intermediate revisions by 3 users not shown)
Line 100: 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 134: 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 273: Line 305:
  
 
|-
 
|-
−
! Explicit Mode
+
! Pebble for Override Clusters
−
| Auto-initilaization for expansed type is a good Eiffel feature, but it is an explicitness violation.
+
| 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.
−
In order to encourage explicitness we could enable to activate an explicit mode wherein expansed type must be explicitly initialized (like attached type).
+
|| || ||
 +
 
 +
|-
 +
! 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.
 +
|| ||
  
−
In explicit mode, this code:
 
−
<code>
 
−
do_something
 
−
    local
 
−
        b: BOOLEAN
 
−
    do
 
−
        -- use 'b'
 
−
    end
 
−
</code>
 
−
make a compilation error and must be replaced by:
 
−
<code>
 
−
do_something
 
−
    local
 
−
        b: BOOLEAN
 
−
    do
 
−
        b := False       
 
−
        -- use 'b'
 
−
    end
 
−
</code>
 
−
|| || ||
 
  
 
|-
 
|-
−
! Pebble for Override Clusters
+
!Editing Text Files
−
| 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.
+
|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 312: Line 369:
 
! XXX
 
! XXX
 
| Allow to use '''?''' in assigner declaration For instance  
 
| Allow to use '''?''' in assigner declaration For instance  
−
<code>
+
<e>
−
  foo: STRING assign set_key_value ("foo", ?) is
+
  foo: STRING assign set_key_value ("foo", ?)
 
     do
 
     do
 
         Result := values.item ("foo")
 
         Result := values.item ("foo")
Line 320: Line 377:
 
  values: HASH_TABLE [STRING, STRING]
 
  values: HASH_TABLE [STRING, STRING]
 
   
 
   
−
  set_key_value (k: STRING; v: STRING) is
+
  set_key_value (k, v: STRING)
 
     do
 
     do
−
         values.force (v,k)
+
         values.force (v, k)
 
     end
 
     end
−
</code>
+
</e>
 
|
 
|
 
|
 
|
Line 336: Line 393:
 
! Exceptions mentioned in method interface
 
! Exceptions mentioned in method interface
 
|| syntax for telling developers about exceptions thrown by a method. e.g.:
 
|| syntax for telling developers about exceptions thrown by a method. e.g.:
−
<code>
+
<e>
−
foo( a : B) : C is
+
foo( a : B): C
−
    require
+
−
        a /= Void
+
 
     exceptions
 
     exceptions
 
         Net_Unreachable, Net_Timeout
 
         Net_Unreachable, Net_Timeout
Line 345: Line 400:
 
         Result := values.item ("foo")
 
         Result := values.item ("foo")
 
     end
 
     end
−
</code>
+
</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.
 
|| 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.
 
|| 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.
Line 355: Line 410:
 
! 'across' with optional 'as'
 
! 'across' with optional 'as'
 
| Allow to use '''across''' without '''as'''  
 
| Allow to use '''across''' without '''as'''  
−
<code>
+
<e>
 
  a_routine
 
  a_routine
 
     do
 
     do
−
         across 1 |..| 10
+
         across 1 |..| 10 loop
−
        loop
+
 
               -- do something
 
               -- do something
 
         end
 
         end
 
     end
 
     end
−
</code>
+
</e>
 
|
 
|
 
|
 
|
Line 371: Line 425:
 
! Simple conversion declaration
 
! Simple conversion declaration
 
| Allow to write a simple conversion statment:
 
| Allow to write a simple conversion statment:
−
<code>
+
<e>
 
class
 
class
 
     CONVERSION_PROPOSAL
 
     CONVERSION_PROPOSAL
Line 388: Line 442:
 
     something: ANOTHER_TYPE
 
     something: ANOTHER_TYPE
 
         do end
 
         do end
−
 
 
end
 
end
−
</code>
+
</e>
 
equivalent to:
 
equivalent to:
−
<code>
+
<e>
 
class
 
class
 
     CURRENT_CONVERSION
 
     CURRENT_CONVERSION
Line 409: Line 462:
 
     something: ANOTHER_TYPE
 
     something: ANOTHER_TYPE
 
         do end
 
         do end
−
 
 
end
 
end
−
</code>
+
</e>
 
| Esaier and more readable declaration
 
| Esaier and more readable declaration
 
|
 
|
 
|
 
|
 +
  
  
 
|-
 
|-
−
! Iterable 'TUPLE'
+
! Customized creation procedure for expanded type
−
| Allow to use an iterator on TUPLE.
+
| Allow to use another creation procedure. `default_create' is not longer required.
 
|
 
|
 
|
 
|
 
|
 
|
 +
  
 
|-
 
|-
−
! Customized creation procedure for expanded type
+
! Remove 'only' postcondition
−
| Require 'default_create' as now but allow to use another creation procedure.
+
| 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 ===
+
== Library ==
 
{| class="wikitable"
 
{| class="wikitable"
 
!ID !! Short Summary !! Pros !! Cons !! More info
 
!ID !! Short Summary !! Pros !! Cons !! More info
Line 448: Line 657:
 
! SQL like where
 
! SQL like where
 
| simmala to do_if, but a function:
 
| simmala to do_if, but a function:
−
  where( test: FUNCTION [ANY, TUPLE [G], BOOLEAN] ) : like Current is
+
<e>
−
      --returns container like current, for items satisfying test
+
where (test: PREDICATE [ANY, TUPLE [G]]): like Current
−
      deferred
+
        -- Items satisfying `test'
−
      end
+
    ...
 +
</e>
 
|
 
|
 
|
 
|
Line 459: Line 669:
 
! slice functions
 
! slice functions
 
|   
 
|   
−
  slice_until, slice_after, slice_after_and_including, etc( test: FUNCTION [ANY, TUPLE [G], BOOLEAN] ) : like Current is
+
<e>
−
    deferred
+
slice_until, slice_after, ... (test: PREDICATE [ANY, TUPLE [G]]): like Current
−
    end
+
    ...
 +
</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>
 
|
 
|
 
|
 
|

Latest revision as of 07: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.

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:
  • Easy queriable
  • Much more appropriate to use a database to store relations (dependencies) between objects.
  • 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 [1]
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".
  • 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.
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:

  • 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: 

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")
  • Unused features are already eliminated in the dead code removal step when finalizing a system.
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.
Retrieved from "https://dev.eiffel.com/index.php?title=EiffelStudio_Wish_List&oldid=15296"