EiffelStudio: an EiffelSoftware project - User contributions [en]

EiffelStudio Wish List

2014-08-03T12:55:15Z

Conaclos: Remove unecessary precisions

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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:
<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>
|| || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-08-03T12:51:58Z

Conaclos: Removing personal proposal

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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:
<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>
|| || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.

A consequence is that expanded types are no longer generic creation ready.
Generic creation ready type could be frozen types with `default_create' as creation procedure.
|
|
|

|-
! 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.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).

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

== Other ==
{| class="wikitable"
!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.
|| ||

|}

Exceptions as Objects

2014-07-02T21:59:03Z

Conaclos: Syntax update 2

[[Category:Exception]]
== Overview ==
This article describes many aspects of Exceptions as Objects (ECMA-367 8.26) which will be implemented in ISE Eiffel. All exceptions will be raised as objects which can be accessed by `last_exception'. Exceptions as objects are known as type EXCEPTION and its descendants. EXCEPTION_MANAGER is introduced to handle common exception class operations, i.e. catch, and ignore.

This doc is from the original working version: http://docs.google.com/Doc?docid=dckspcv8_9htpfm4&hl=en

== Exception class hierarchy ==
{{Red|EXCEPTION}}
{{Red|SYSTEM_EXCEPTION}}
{{Red|MACHINE_EXCEPTION}}
{{Red|OPERATING_SYSTEM_EXCEPTION}}
{{Red|COM_FAILURE}}
{{Red|OPERATING_SYSTEM_FAILURE}}
{{Red|OPERATING_SYSTEM_SIGNAL_FAILURE}}
{{Red|HARDWARE_EXCEPTION}}
{{Red|FLOATING_POINT_FAILURE}}
{{Red|EIFFEL_EXCEPTION}}
{{Red|LANGUAGE_EXCEPTION}}
{{Red|BAD_INSPECT_VALUE}}
{{Red|VOID_TARGET}}
{{Red|VOID_ASSIGNED_TO_EXPANDED}}
{{Red|ROUTINE_FAILURE}}
EIFFELSTUDIO_SPECIFIC_LANGUAGE_EXCEPTION
CREATE_ON_DEFERRED
ADDRESS_APPLIED_TO_MELTED_FEATURE
{{Red|EIFFEL_RUNTIME_EXCEPTION}}
NO_MORE_MEMORY
DATA_EXCEPTION
IO_FAILURE
SERIALIZATION_FAILURE
MISMATCH_FAILURE
EXTERNAL_FAILURE-- Only used for threads at the moment
EIFFEL_RUNTIME_PANIC
{{Red|ASSERTION_VIOLATION}}
{{Red|INVARIANT_VIOLATION}}
{{Red|PRECONDITION_VIOLATION}}
{{Red|POSTCONDITION_VIOLATION}}
{{Red|CHECK_VIOLATION}}
{{Red|VARIANT_VIOLATION}}
{{Red|OLD_VIOLATION}}
{{Red|LOOP_INVARIANT_VIOLATION}}
{{Red|DEVELOPER_EXCEPTION}}
{{Red|OBSOLETE_EXCEPTION}}
RESUMPTION_FAILURE Was RESUMPTION_FAILED.
RESCUE_FAILURE --------- SHOULD NOT APPLY ANY MORE WITH ISO/ECMA, CHECK!!!
EXCEPTION_IN_SIGNAL_HANDLER_FAILURE

Classes in red plus EXCEPTION_MANAGER will be placed at base\elks\kernel\exceptions\.
The rests are ise specific.
 
'''Terminology'''
We use _EXCEPTION for intermediate nodes in the hierarchy; when we need a term in the leaves of the hierarchy we don't use EXCEPTION but

* _VIOLATION for assertions (also used for ASSERTION_VIOLATION, an intermediate node)
* _FAILURE otherwise

This is consistent with Eiffel exception terminology since from the viewpoint of Eiffel these things have failed, for example a signal was not handled properly. The Eiffel runtime is causing an exception in the Eiffel code as a result, but the original event was a failure. Hence SERIALIZATION_FAILURE etc.

== Raise and catch an exception ==

==== Catching an exception ====
All exceptions can possibly be caught. `is_caught' is set by default. Only the given type of exception is `ignore'd in EXCEPTION_MANAGER if possible, it hence is not caught.
The caught exception can be accessed by `last_exception'.

==== Raising an exception ====
There are two types of exceptions concerning how an exception is raised.
* System raised
Exception raised through the runtime. Most exceptions of this type are predefine as classes in base library. i.e. assertion violations, no memory exceptions and routine failures.
* User raised
User raised exceptions are initialized by users and raised by explicit call of {EXCEPTION}.raise.

Theoretically the runtime can raise any exceptions known. A user can only raise an EXCEPTION that is `is_raisable'. `is_raisable' is possible true only when the exception is of DEVELOPER_EXCEPTION. This means only raising a DEVELOPER_EXCEPTION or its descendant is guaranteed correct.

== Ignoring, continuing an exception ==

Quote from ECMA 8.26.12:
It is possible, through routines of the Kernel Library class EXCEPTION, to ensure that exceptions of certain types be:

* Ignored: lead to no change of non-exception semantics.
* Continued: lead to execution of a programmer-specified routine, then to continuation of the execution according to non-exception semantics.

An ignorable exception can be ignored. When an exception is ignored, the raising does nothing as if non-exception semantics.
What are the exceptions not ignorable?

Related queries in EXCEPTION:

<eiffel>
is_ignored: BOOLEAN
is_caught: BOOLEAN
is_ignorable: BOOLEAN
</eiffel>

Related routines in EXCEPTION_MANAGER:

<eiffel>
is_caught (a_exception: TYPE [EXCEPTION]): BOOLEAN
is_ignored (a_exception: TYPE [EXCEPTION]): BOOLEAN
is_ignorable (a_exception: TYPE [EXCEPTION]): BOOLEAN
catch (a_exception: TYPE [EXCEPTION])
ignore (a_exception: TYPE [EXCEPTION])
set_is_ignored (a_exception: TYPE [EXCEPTION]; a_ignored: BOOLEAN)
</eiffel>

== `origin' VS `cause' ==

* The origin of an exception is, among all exceptions that have so far been triggered but not handled, the most recent one that is not a ROUTINE_FAILURE. Because a ROUTINE_FAILURE is always the result of an exception of another kind, the `origin' is always defined.

* The `cause' of an exception is only interesting in the case of an exception triggered in a rescue clause. In that case the exception is the result of incomplete handling of another exception (which might be a ROUTINE_FAILURE or any other kind). Then the `cause' is that other exception.

* If an exception was not triggered in a rescue clause, its `cause' is the exception itself.

== Exception at rescue clause ==
See the following diagram:

[[Image:exception_in_rescue.png]]

Exception e2 is kept as `cause' at d.f4 in which e3 is raised, and being called in rescue clause r2. In this case e3 is accessible by `last_exception' and e2 is accessible by `cause' of e3.
 
 

A behavior should be clarified, that when an exception occurs deep in execution level of a rescue clause, `last_exception' is understood as "last unhandled exception".

 
1. A new exception causes "last_exception" to be saved somewhere before
entering "rescue" clause. After that the new exception object is attached to
"last_exception".

2. If an exception is not handled (there is no rescue clause or "retry" is not
performed), a new exception object "ROUTINE_FAILURE" is created, its attribute
"original_exception" is set to "last_exception", and "last_exception" is set to
this new "ROUTINE_FAILURE" object.

3. If an exception is handled ("retry" is executed), "last_exception" is attached
a value saved in step 1.

Example:
If "last_exception" in the following code snippet is modified
by the call to feature "h" that raises an exception internally and handles it?
<eiffel>
rescue
-- "last_exception" is set to "X".
-- Call feature that raises exception "Y", but handles it.
h

-- Is "last_exception" set to "X" or to "Y"?
-- The answer is X.
</eiffel>

== OLD_VIOLATION ==

OLD_VIOLATION behaves similarly with ROUTINE_FAILURE. In other words, OLD_VIOLATION is never a "root" exception of an exception chain. According to ECMA 8.26.11, OLD_VIOLATION should be treated as a "root" exception. But I believe it is more interesting to know the cause (original exception) of the old voilation. This will be clarified soon.

== Class ANY ==
This is now done in EXCEPTION_MANAGER.
<eiffel>
class ANY
...
feature -- Exception

frozen last_exception: EXCEPTION
-- Last exception
external
"built_in"
end
...
</eiffel>

== Class EXCEPTION ==
<eiffel>
deferred class interface
EXCEPTION

feature -- Access

code: INTEGER_32
-- Code of the exception.
-- |Maybe we don't need this anymore

exception_trace: STRING_8
-- String representation of current exception trace

meaning: STRING_8
-- A message in English describing what `except' is

message: STRING_8
-- Tag of current exception

original: EXCEPTION
-- Original exception that triggered current exception

cause: EXCEPTION
-- Unhandled exception before current exception was triggered in a rescue clause

recipient_name: STRING_8
-- Name of the routine whose execution was
-- interrupted by current exception

type_name: STRING_8
-- Name of the class that includes the recipient
-- of original form of current exception

feature -- Status report

is_caught: BOOLEAN
-- If set, exception is raised.
ensure
not_is_caught_implies_is_ignorable: not Result implies is_ignorable
not_is_ignored: not is_ignored

is_ignorable: BOOLEAN
-- Is current exception ignorable?

is_ignored: BOOLEAN
-- If set, no exception is raised.
ensure
is_ignored_implies_is_ignorable: Result implies is_ignorable
not_is_caught: not is_caught

is_raisable: BOOLEAN
-- Is current exception raisable by raise?

feature -- Raise

raise
-- Raise current exception
require
is_raisable: is_raisable

end -- class EXCEPTION
</eiffel>

== Class EXCEPTION_MANAGER ==
<eiffel>
class interface
EXCEPTION_MANAGER

create
default_create

feature -- Access

frozen last_exception: EXCEPTION
-- Last exception

feature -- Status report

is_caught (a_exception: TYPE [EXCEPTION]): BOOLEAN
-- If set, type of `a_exception' is raised.
ensure
not_is_ignored: not is_ignored (a_exception)

is_ignorable (a_exception: TYPE [EXCEPTION]): BOOLEAN
-- If set, type of `a_exception' is ignorable.

is_ignored (a_exception: TYPE [EXCEPTION]): BOOLEAN
-- If set, type of `a_exception' is not raised.
ensure
not_is_caught: not is_caught (a_exception)

feature -- Status setting

catch (a_exception: TYPE [EXCEPTION])
-- Set type of `a_exception' is_ignored.
require
a_exception_not_void: a_exception /= Void
ensure
is_ignored: not is_ignored (a_exception)

ignore (a_exception: TYPE [EXCEPTION])
-- Make sure that any exception of code `code' will be
-- ignored. This is not the default.
require
a_exception_not_void: a_exception /= Void
is_ignorable: is_ignorable (a_exception)
ensure
is_caught: is_ignored (a_exception)

set_is_ignored (a_exception: TYPE [EXCEPTION]; a_ignored: BOOLEAN)
-- Set type of `a_exception' to be `a_ignored'.
require
a_exception_not_void: a_exception /= Void
a_ignored_implies_is_ignorable: a_ignored implies is_ignorable (a_exception)
ensure
is_ignored_set: is_ignored (a_exception) = a_ignored

end -- class EXCEPTION_MANAGER
</eiffel>

== Default rescue ==
As specified in ECMA, `default_rescue' in ANY or its descendant is called as unqualified when an internal routine or an attributes with no rescue clause fails.
We choose not to invoke it when it is not redefined, or this will be too expensive.

<eiffel>
class ANY
...
default_rescue
do
end
...
end
</eiffel>

== Sample code: Raising and catching developer exception ==
<eiffel>
class
MY_EXCEPTION

inherit
DEVELOPER_EXCEPTION

end
</eiffel>
<eiffel>
class
A

feature

f
local
retried: BOOLEAN
do
if not retried then
my_exception.raise -- Raise user-defined exception.
end
rescue
if last_exception = my_exception then -- Check the exception object was the one user defined.
print ("True" + "%N")
else
print ("False" + "%N")
end
end

my_exception: MY_EXCEPTION
once
create Result
end

end
</eiffel>
<eiffel>
class
APPLICATION

inherit
A

create
make

feature -- Initialization

make
-- Run application.
local
a: A
retried: BOOLEAN
do
if not retried then
create a
a.f
end
rescue
retried := True

-- `last_exception' is an object of ROUTINE_FAILURE?
if attached {ROUTINE_FAILURE} (create {EXCEPTION_MANAGER}).last_exception as l_exception then
print ("True" + "%N")
else
print ("False" + "%N")
end

-- `original' exception is the one caused `last_exception'?
if last_exception.original = my_exception then
print ("True" + "%N")
else
print ("False" + "%N")
end
retry
end

end -- class APPLICATION
</eiffel>

Exceptions as Objects

2014-07-02T21:58:13Z

Conaclos: Style update

[[Category:Exception]]
== Overview ==
This article describes many aspects of Exceptions as Objects (ECMA-367 8.26) which will be implemented in ISE Eiffel. All exceptions will be raised as objects which can be accessed by `last_exception'. Exceptions as objects are known as type EXCEPTION and its descendants. EXCEPTION_MANAGER is introduced to handle common exception class operations, i.e. catch, and ignore.

This doc is from the original working version: http://docs.google.com/Doc?docid=dckspcv8_9htpfm4&hl=en

== Exception class hierarchy ==
{{Red|EXCEPTION}}
{{Red|SYSTEM_EXCEPTION}}
{{Red|MACHINE_EXCEPTION}}
{{Red|OPERATING_SYSTEM_EXCEPTION}}
{{Red|COM_FAILURE}}
{{Red|OPERATING_SYSTEM_FAILURE}}
{{Red|OPERATING_SYSTEM_SIGNAL_FAILURE}}
{{Red|HARDWARE_EXCEPTION}}
{{Red|FLOATING_POINT_FAILURE}}
{{Red|EIFFEL_EXCEPTION}}
{{Red|LANGUAGE_EXCEPTION}}
{{Red|BAD_INSPECT_VALUE}}
{{Red|VOID_TARGET}}
{{Red|VOID_ASSIGNED_TO_EXPANDED}}
{{Red|ROUTINE_FAILURE}}
EIFFELSTUDIO_SPECIFIC_LANGUAGE_EXCEPTION
CREATE_ON_DEFERRED
ADDRESS_APPLIED_TO_MELTED_FEATURE
{{Red|EIFFEL_RUNTIME_EXCEPTION}}
NO_MORE_MEMORY
DATA_EXCEPTION
IO_FAILURE
SERIALIZATION_FAILURE
MISMATCH_FAILURE
EXTERNAL_FAILURE-- Only used for threads at the moment
EIFFEL_RUNTIME_PANIC
{{Red|ASSERTION_VIOLATION}}
{{Red|INVARIANT_VIOLATION}}
{{Red|PRECONDITION_VIOLATION}}
{{Red|POSTCONDITION_VIOLATION}}
{{Red|CHECK_VIOLATION}}
{{Red|VARIANT_VIOLATION}}
{{Red|OLD_VIOLATION}}
{{Red|LOOP_INVARIANT_VIOLATION}}
{{Red|DEVELOPER_EXCEPTION}}
{{Red|OBSOLETE_EXCEPTION}}
RESUMPTION_FAILURE Was RESUMPTION_FAILED.
RESCUE_FAILURE --------- SHOULD NOT APPLY ANY MORE WITH ISO/ECMA, CHECK!!!
EXCEPTION_IN_SIGNAL_HANDLER_FAILURE

Classes in red plus EXCEPTION_MANAGER will be placed at base\elks\kernel\exceptions\.
The rests are ise specific.
 
'''Terminology'''
We use _EXCEPTION for intermediate nodes in the hierarchy; when we need a term in the leaves of the hierarchy we don't use EXCEPTION but

* _VIOLATION for assertions (also used for ASSERTION_VIOLATION, an intermediate node)
* _FAILURE otherwise

This is consistent with Eiffel exception terminology since from the viewpoint of Eiffel these things have failed, for example a signal was not handled properly. The Eiffel runtime is causing an exception in the Eiffel code as a result, but the original event was a failure. Hence SERIALIZATION_FAILURE etc.

== Raise and catch an exception ==

==== Catching an exception ====
All exceptions can possibly be caught. `is_caught' is set by default. Only the given type of exception is `ignore'd in EXCEPTION_MANAGER if possible, it hence is not caught.
The caught exception can be accessed by `last_exception'.

==== Raising an exception ====
There are two types of exceptions concerning how an exception is raised.
* System raised
Exception raised through the runtime. Most exceptions of this type are predefine as classes in base library. i.e. assertion violations, no memory exceptions and routine failures.
* User raised
User raised exceptions are initialized by users and raised by explicit call of {EXCEPTION}.raise.

Theoretically the runtime can raise any exceptions known. A user can only raise an EXCEPTION that is `is_raisable'. `is_raisable' is possible true only when the exception is of DEVELOPER_EXCEPTION. This means only raising a DEVELOPER_EXCEPTION or its descendant is guaranteed correct.

== Ignoring, continuing an exception ==

Quote from ECMA 8.26.12:
It is possible, through routines of the Kernel Library class EXCEPTION, to ensure that exceptions of certain types be:

* Ignored: lead to no change of non-exception semantics.
* Continued: lead to execution of a programmer-specified routine, then to continuation of the execution according to non-exception semantics.

An ignorable exception can be ignored. When an exception is ignored, the raising does nothing as if non-exception semantics.
What are the exceptions not ignorable?

Related queries in EXCEPTION:

<eiffel>
is_ignored: BOOLEAN
is_caught: BOOLEAN
is_ignorable: BOOLEAN
</eiffel>

Related routines in EXCEPTION_MANAGER:

<eiffel>
is_caught (a_exception: TYPE [EXCEPTION]): BOOLEAN
is_ignored (a_exception: TYPE [EXCEPTION]): BOOLEAN
is_ignorable (a_exception: TYPE [EXCEPTION]): BOOLEAN
catch (a_exception: TYPE [EXCEPTION])
ignore (a_exception: TYPE [EXCEPTION])
set_is_ignored (a_exception: TYPE [EXCEPTION]; a_ignored: BOOLEAN)
</eiffel>

== `origin' VS `cause' ==

* The origin of an exception is, among all exceptions that have so far been triggered but not handled, the most recent one that is not a ROUTINE_FAILURE. Because a ROUTINE_FAILURE is always the result of an exception of another kind, the `origin' is always defined.

* The `cause' of an exception is only interesting in the case of an exception triggered in a rescue clause. In that case the exception is the result of incomplete handling of another exception (which might be a ROUTINE_FAILURE or any other kind). Then the `cause' is that other exception.

* If an exception was not triggered in a rescue clause, its `cause' is the exception itself.

== Exception at rescue clause ==
See the following diagram:

[[Image:exception_in_rescue.png]]

Exception e2 is kept as `cause' at d.f4 in which e3 is raised, and being called in rescue clause r2. In this case e3 is accessible by `last_exception' and e2 is accessible by `cause' of e3.
 
 

A behavior should be clarified, that when an exception occurs deep in execution level of a rescue clause, `last_exception' is understood as "last unhandled exception".

 
1. A new exception causes "last_exception" to be saved somewhere before
entering "rescue" clause. After that the new exception object is attached to
"last_exception".

2. If an exception is not handled (there is no rescue clause or "retry" is not
performed), a new exception object "ROUTINE_FAILURE" is created, its attribute
"original_exception" is set to "last_exception", and "last_exception" is set to
this new "ROUTINE_FAILURE" object.

3. If an exception is handled ("retry" is executed), "last_exception" is attached
a value saved in step 1.

Example:
If "last_exception" in the following code snippet is modified
by the call to feature "h" that raises an exception internally and handles it?
<eiffel>
rescue
-- "last_exception" is set to "X".
-- Call feature that raises exception "Y", but handles it.
h

-- Is "last_exception" set to "X" or to "Y"?
-- The answer is X.
</eiffel>

== OLD_VIOLATION ==

OLD_VIOLATION behaves similarly with ROUTINE_FAILURE. In other words, OLD_VIOLATION is never a "root" exception of an exception chain. According to ECMA 8.26.11, OLD_VIOLATION should be treated as a "root" exception. But I believe it is more interesting to know the cause (original exception) of the old voilation. This will be clarified soon.

== Class ANY ==
This is now done in EXCEPTION_MANAGER.
<eiffel>
class ANY
...
feature -- Exception

frozen last_exception: EXCEPTION
-- Last exception
external
"built_in"
end
...
</eiffel>

== Class EXCEPTION ==
<eiffel>
deferred class interface
EXCEPTION

feature -- Access

code: INTEGER_32
-- Code of the exception.
-- |Maybe we don't need this anymore

exception_trace: STRING_8
-- String representation of current exception trace

meaning: STRING_8
-- A message in English describing what `except' is

message: STRING_8
-- Tag of current exception

original: EXCEPTION
-- Original exception that triggered current exception

cause: EXCEPTION
-- Unhandled exception before current exception was triggered in a rescue clause

recipient_name: STRING_8
-- Name of the routine whose execution was
-- interrupted by current exception

type_name: STRING_8
-- Name of the class that includes the recipient
-- of original form of current exception

feature -- Status report

is_caught: BOOLEAN
-- If set, exception is raised.
ensure
not_is_caught_implies_is_ignorable: not Result implies is_ignorable
not_is_ignored: not is_ignored

is_ignorable: BOOLEAN
-- Is current exception ignorable?

is_ignored: BOOLEAN
-- If set, no exception is raised.
ensure
is_ignored_implies_is_ignorable: Result implies is_ignorable
not_is_caught: not is_caught

is_raisable: BOOLEAN
-- Is current exception raisable by raise?

feature -- Raise

raise
-- Raise current exception
require
is_raisable: is_raisable

end -- class EXCEPTION
</eiffel>

== Class EXCEPTION_MANAGER ==
<eiffel>
class interface
EXCEPTION_MANAGER

create
default_create

feature -- Access

frozen last_exception: EXCEPTION
-- Last exception

feature -- Status report

is_caught (a_exception: TYPE [EXCEPTION]): BOOLEAN
-- If set, type of `a_exception' is raised.
ensure
not_is_ignored: not is_ignored (a_exception)

is_ignorable (a_exception: TYPE [EXCEPTION]): BOOLEAN
-- If set, type of `a_exception' is ignorable.

is_ignored (a_exception: TYPE [EXCEPTION]): BOOLEAN
-- If set, type of `a_exception' is not raised.
ensure
not_is_caught: not is_caught (a_exception)

feature -- Status setting

catch (a_exception: TYPE [EXCEPTION])
-- Set type of `a_exception' is_ignored.
require
a_exception_not_void: a_exception /= Void
ensure
is_ignored: not is_ignored (a_exception)

ignore (a_exception: TYPE [EXCEPTION])
-- Make sure that any exception of code `code' will be
-- ignored. This is not the default.
require
a_exception_not_void: a_exception /= Void
is_ignorable: is_ignorable (a_exception)
ensure
is_caught: is_ignored (a_exception)

set_is_ignored (a_exception: TYPE [EXCEPTION]; a_ignored: BOOLEAN)
-- Set type of `a_exception' to be `a_ignored'.
require
a_exception_not_void: a_exception /= Void
a_ignored_implies_is_ignorable: a_ignored implies is_ignorable (a_exception)
ensure
is_ignored_set: is_ignored (a_exception) = a_ignored

end -- class EXCEPTION_MANAGER
</eiffel>

== Default rescue ==
As specified in ECMA, `default_rescue' in ANY or its descendant is called as unqualified when an internal routine or an attributes with no rescue clause fails.
We choose not to invoke it when it is not redefined, or this will be too expensive.

<eiffel>
class ANY
...
default_rescue is
do
end
...
end
</eiffel>

== Sample code: Raising and catching developer exception ==
<eiffel>
class
MY_EXCEPTION

inherit
DEVELOPER_EXCEPTION

end
</eiffel>
<eiffel>
class
A

feature

f
local
retried: BOOLEAN
do
if not retried then
my_exception.raise -- Raise user-defined exception.
end
rescue
if last_exception = my_exception then -- Check the exception object was the one user defined.
print ("True" + "%N")
else
print ("False" + "%N")
end
end

my_exception: MY_EXCEPTION
once
create Result
end

end
</eiffel>
<eiffel>
class
APPLICATION

inherit
A

create
make

feature -- Initialization

make
-- Run application.
local
a: A
retried: BOOLEAN
do
if not retried then
create a
a.f
end
rescue
retried := True

-- `last_exception' is an object of ROUTINE_FAILURE?
if attached {ROUTINE_FAILURE} (create {EXCEPTION_MANAGER}).last_exception as l_exception then
print ("True" + "%N")
else
print ("False" + "%N")
end

-- `original' exception is the one caused `last_exception'?
if last_exception.original = my_exception then
print ("True" + "%N")
else
print ("False" + "%N")
end
retry
end

end -- class APPLICATION
</eiffel>

Exceptions as Objects

2014-07-02T21:47:36Z

Conaclos: Update syntax

[[Category:Exception]]
== Overview ==
This article describes many aspects of Exceptions as Objects (ECMA-367 8.26) which will be implemented in ISE Eiffel. All exceptions will be raised as objects which can be accessed by `last_exception'. Exceptions as objects are known as type EXCEPTION and its descendants. EXCEPTION_MANAGER is introduced to handle common exception class operations, i.e. catch, and ignore.

This doc is from the original working version: http://docs.google.com/Doc?docid=dckspcv8_9htpfm4&hl=en

== Exception class hierarchy ==
{{Red|EXCEPTION}}
{{Red|SYSTEM_EXCEPTION}}
{{Red|MACHINE_EXCEPTION}}
{{Red|OPERATING_SYSTEM_EXCEPTION}}
{{Red|COM_FAILURE}}
{{Red|OPERATING_SYSTEM_FAILURE}}
{{Red|OPERATING_SYSTEM_SIGNAL_FAILURE}}
{{Red|HARDWARE_EXCEPTION}}
{{Red|FLOATING_POINT_FAILURE}}
{{Red|EIFFEL_EXCEPTION}}
{{Red|LANGUAGE_EXCEPTION}}
{{Red|BAD_INSPECT_VALUE}}
{{Red|VOID_TARGET}}
{{Red|VOID_ASSIGNED_TO_EXPANDED}}
{{Red|ROUTINE_FAILURE}}
EIFFELSTUDIO_SPECIFIC_LANGUAGE_EXCEPTION
CREATE_ON_DEFERRED
ADDRESS_APPLIED_TO_MELTED_FEATURE
{{Red|EIFFEL_RUNTIME_EXCEPTION}}
NO_MORE_MEMORY
DATA_EXCEPTION
IO_FAILURE
SERIALIZATION_FAILURE
MISMATCH_FAILURE
EXTERNAL_FAILURE-- Only used for threads at the moment
EIFFEL_RUNTIME_PANIC
{{Red|ASSERTION_VIOLATION}}
{{Red|INVARIANT_VIOLATION}}
{{Red|PRECONDITION_VIOLATION}}
{{Red|POSTCONDITION_VIOLATION}}
{{Red|CHECK_VIOLATION}}
{{Red|VARIANT_VIOLATION}}
{{Red|OLD_VIOLATION}}
{{Red|LOOP_INVARIANT_VIOLATION}}
{{Red|DEVELOPER_EXCEPTION}}
{{Red|OBSOLETE_EXCEPTION}}
RESUMPTION_FAILURE Was RESUMPTION_FAILED.
RESCUE_FAILURE --------- SHOULD NOT APPLY ANY MORE WITH ISO/ECMA, CHECK!!!
EXCEPTION_IN_SIGNAL_HANDLER_FAILURE

Classes in red plus EXCEPTION_MANAGER will be placed at base\elks\kernel\exceptions\.
The rests are ise specific.
 
'''Terminology'''
We use _EXCEPTION for intermediate nodes in the hierarchy; when we need a term in the leaves of the hierarchy we don't use EXCEPTION but

* _VIOLATION for assertions (also used for ASSERTION_VIOLATION, an intermediate node)
* _FAILURE otherwise

This is consistent with Eiffel exception terminology since from the viewpoint of Eiffel these things have failed, for example a signal was not handled properly. The Eiffel runtime is causing an exception in the Eiffel code as a result, but the original event was a failure. Hence SERIALIZATION_FAILURE etc.

== Raise and catch an exception ==

==== Catching an exception ====
All exceptions can possibly be caught. `is_caught' is set by default. Only the given type of exception is `ignore'd in EXCEPTION_MANAGER if possible, it hence is not caught.
The caught exception can be accessed by `last_exception'.

==== Raising an exception ====
There are two types of exceptions concerning how an exception is raised.
* System raised
Exception raised through the runtime. Most exceptions of this type are predefine as classes in base library. i.e. assertion violations, no memory exceptions and routine failures.
* User raised
User raised exceptions are initialized by users and raised by explicit call of {EXCEPTION}.raise.

Theoretically the runtime can raise any exceptions known. A user can only raise an EXCEPTION that is `is_raisable'. `is_raisable' is possible true only when the exception is of DEVELOPER_EXCEPTION. This means only raising a DEVELOPER_EXCEPTION or its descendant is guaranteed correct.

== Ignoring, continuing an exception ==

Quote from ECMA 8.26.12:
It is possible, through routines of the Kernel Library class EXCEPTION, to ensure that exceptions of certain types be:

* Ignored: lead to no change of non-exception semantics.
* Continued: lead to execution of a programmer-specified routine, then to continuation of the execution according to non-exception semantics.

An ignorable exception can be ignored. When an exception is ignored, the raising does nothing as if non-exception semantics.
What are the exceptions not ignorable?

Related queries in EXCEPTION:

<eiffel>
is_ignored: BOOLEAN
is_caught: BOOLEAN
is_ignorable: BOOLEAN
</eiffel>

Related routines in EXCEPTION_MANAGER:

<eiffel>
is_caught (a_exception: TYPE [EXCEPTION]): BOOLEAN
is_ignored (a_exception: TYPE [EXCEPTION]): BOOLEAN
is_ignorable (a_exception: TYPE [EXCEPTION]): BOOLEAN
catch (a_exception: TYPE [EXCEPTION])
ignore (a_exception: TYPE [EXCEPTION])
set_is_ignored (a_exception: TYPE [EXCEPTION]; a_ignored: BOOLEAN)
</eiffel>

== `origin' VS `cause' ==

* The origin of an exception is, among all exceptions that have so far been triggered but not handled, the most recent one that is not a ROUTINE_FAILURE. Because a ROUTINE_FAILURE is always the result of an exception of another kind, the `origin' is always defined.

* The `cause' of an exception is only interesting in the case of an exception triggered in a rescue clause. In that case the exception is the result of incomplete handling of another exception (which might be a ROUTINE_FAILURE or any other kind). Then the `cause' is that other exception.

* If an exception was not triggered in a rescue clause, its `cause' is the exception itself.

== Exception at rescue clause ==
See the following diagram:

[[Image:exception_in_rescue.png]]

Exception e2 is kept as `cause' at d.f4 in which e3 is raised, and being called in rescue clause r2. In this case e3 is accessible by `last_exception' and e2 is accessible by `cause' of e3.
 
 

A behavior should be clarified, that when an exception occurs deep in execution level of a rescue clause, `last_exception' is understood as "last unhandled exception".

 
1. A new exception causes "last_exception" to be saved somewhere before
entering "rescue" clause. After that the new exception object is attached to
"last_exception".

2. If an exception is not handled (there is no rescue clause or "retry" is not
performed), a new exception object "ROUTINE_FAILURE" is created, its attribute
"original_exception" is set to "last_exception", and "last_exception" is set to
this new "ROUTINE_FAILURE" object.

3. If an exception is handled ("retry" is executed), "last_exception" is attached
a value saved in step 1.

Example:
If "last_exception" in the following code snippet is modified
by the call to feature "h" that raises an exception internally and handles it?
<eiffel>
rescue
-- "last_exception" is set to "X".
-- Call feature that raises exception "Y", but handles it.
h

-- Is "last_exception" set to "X" or to "Y"?
-- The answer is X.
</eiffel>

== OLD_VIOLATION ==

OLD_VIOLATION behaves similarly with ROUTINE_FAILURE. In other words, OLD_VIOLATION is never a "root" exception of an exception chain. According to ECMA 8.26.11, OLD_VIOLATION should be treated as a "root" exception. But I believe it is more interesting to know the cause (original exception) of the old voilation. This will be clarified soon.

== Class ANY ==
This is now done in EXCEPTION_MANAGER.
<eiffel>
class ANY
...
feature -- Exception

frozen last_exception: EXCEPTION
-- Last exception
external
"built_in"
end
...
</eiffel>

== Class EXCEPTION ==
<eiffel>
deferred class interface
EXCEPTION

feature -- Access

code: INTEGER_32
-- Code of the exception.
-- |Maybe we don't need this anymore

exception_trace: STRING_8
-- String representation of current exception trace

meaning: STRING_8
-- A message in English describing what `except' is

message: STRING_8
-- Tag of current exception

original: EXCEPTION
-- Original exception that triggered current exception

cause: EXCEPTION
-- Unhandled exception before current exception was triggered in a rescue clause

recipient_name: STRING_8
-- Name of the routine whose execution was
-- interrupted by current exception

type_name: STRING_8
-- Name of the class that includes the recipient
-- of original form of current exception

feature -- Status report

is_caught: BOOLEAN
-- If set, exception is raised.
ensure
not_is_caught_implies_is_ignorable: not Result implies is_ignorable
not_is_ignored: not is_ignored

is_ignorable: BOOLEAN
-- Is current exception ignorable?

is_ignored: BOOLEAN
-- If set, no exception is raised.
ensure
is_ignored_implies_is_ignorable: Result implies is_ignorable
not_is_caught: not is_caught

is_raisable: BOOLEAN
-- Is current exception raisable by raise?

feature -- Raise

raise
-- Raise current exception
require
is_raisable: is_raisable

end -- class EXCEPTION
</eiffel>

== Class EXCEPTION_MANAGER ==
<eiffel>
class interface
EXCEPTION_MANAGER

create
default_create

feature -- Access

frozen last_exception: EXCEPTION
-- Last exception

feature -- Status report

is_caught (a_exception: TYPE [EXCEPTION]): BOOLEAN
-- If set, type of `a_exception' is raised.
ensure
not_is_ignored: not is_ignored (a_exception)

is_ignorable (a_exception: TYPE [EXCEPTION]): BOOLEAN
-- If set, type of `a_exception' is ignorable.

is_ignored (a_exception: TYPE [EXCEPTION]): BOOLEAN
-- If set, type of `a_exception' is not raised.
ensure
not_is_caught: not is_caught (a_exception)

feature -- Status setting

catch (a_exception: TYPE [EXCEPTION])
-- Set type of `a_exception' is_ignored.
require
a_exception_not_void: a_exception /= Void
ensure
is_ignored: not is_ignored (a_exception)

ignore (a_exception: TYPE [EXCEPTION])
-- Make sure that any exception of code `code' will be
-- ignored. This is not the default.
require
a_exception_not_void: a_exception /= Void
is_ignorable: is_ignorable (a_exception)
ensure
is_caught: is_ignored (a_exception)

set_is_ignored (a_exception: TYPE [EXCEPTION]; a_ignored: BOOLEAN)
-- Set type of `a_exception' to be `a_ignored'.
require
a_exception_not_void: a_exception /= Void
a_ignored_implies_is_ignorable: a_ignored implies is_ignorable (a_exception)
ensure
is_ignored_set: is_ignored (a_exception) = a_ignored

end -- class EXCEPTION_MANAGER
</eiffel>

== Default rescue ==
As specified in ECMA, `default_rescue' in ANY or its descendant is called as unqualified when an internal routine or an attributes with no rescue clause fails.
We choose not to invoke it when it is not redefined, or this will be too expensive.

<eiffel>
class ANY
...
default_rescue is
do
end
...
end
</eiffel>

== Sample code: Raising and catching developer exception ==
<eiffel>
class
MY_EXCEPTION

inherit
DEVELOPER_EXCEPTION

end
</eiffel>
<eiffel>
class
A

feature

f is
local
retried: BOOLEAN
do
if not retried then
my_exception.raise -- Raise user-defined exception.
end
rescue
if last_exception = my_exception then -- Check the exception object was the one user defined.
print ("True" + "%N")
else
print ("False" + "%N")
end
end

my_exception: MY_EXCEPTION is
once
create Result
end

end
</eiffel>
<eiffel>
class
APPLICATION

inherit
A

create
make

feature -- Initialization

make is
-- Run application.
local
a: A
retried: BOOLEAN
do
if not retried then
create a
a.f
end
rescue
retried := True

-- `last_exception' is an object of ROUTINE_FAILURE?
if attached {ROUTINE_FAILURE} (create {EXCEPTION_MANAGER}).last_exception as l_exception then
print ("True" + "%N")
else
print ("False" + "%N")
end

-- `original' exception is the one caused `last_exception'?
if last_exception.original = my_exception then
print ("True" + "%N")
else
print ("False" + "%N")
end
retry
end

end -- class APPLICATION
</eiffel>

EiffelStudio Wish List

2014-05-16T21:56:53Z

Conaclos: readability improvement

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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:
<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>
|| || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.

A consequence is that expanded types are no longer generic creation ready.
Generic creation ready type could be frozen types with `default_create' as creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class PROPOSITION feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class CURRENT_STANDARD feature {NONE}
internal_something: A_TYPE
do end
end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
* How express type interval?
|

|-
! 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.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).

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

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-05-16T21:48:35Z

Conaclos: Fix terminolgy

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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:
<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>
|| || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.

A consequence is that expanded types are no longer generic creation ready.
Generic creation ready type could be frozen types with `default_create' as creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class PROPOSITION feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class CURRENT_STANDARD feature {NONE}
internal_something: A_TYPE
do end
end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
* How express type interval?
|

|-
! 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.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).

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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request 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>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-05-16T21:43:38Z

Conaclos: Adding cons for Empty braces exportation notation

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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:
<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>
|| || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.

A consequence is that expanded types are no longer generic creation ready.
Generic creation ready type could be frozen types with `default_create' as creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class PROPOSITION feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class CURRENT_STANDARD feature {NONE}
internal_something: A_TYPE
do end
end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
* How express type interval?
|

|-
! 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.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).

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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

Default and explicit variance

2014-05-11T17:09:31Z

Conaclos: Discard the extaended variant typing

[[Category:ECMA]]
[[Category:Catcall]]
{{Research}}
== Introduction ==
In first the variant typing is exposed. It checks all catcall checkpoints.
In second the inroduced mechanism is compared against other.

== Variant typing ==
What is the advantages of covariance compared to a novariant typing?
* explicit and adaptative interface
* One routine

=== Variant typing ===
* A variant entity has '''the most restrictive type'''.
* A variant entity requires a simple object test to use the entity with the '''expected type'''.

Examples are available in next sections.

=== Feature redefinition ===
* Covariant redefinition of request result is allowed (as currently).
* Covariant redefinition of feature argument requires a variant typing on redefined argument or first definition.
'''The most restrictive type''' for a variant type argument is the type of the first definition.

The first rule is a stronger postcondition. The current semantic is not changed.

'''example 1:''' covariant redefinition of feature argument with 'variant' typing on redefined argument

Note:
* The object test is not needed.
* the type is not repeated in the object test.
* In the class interface the 'variant' is removed. Indeed, it is not possible to call 'eat' on an entity of type COW with a parameter of type FOOD.

<e>
class
ANIMAL

feature -- Access
last: FOOD

feature -- Eating
eat (f: like last)
require
True
do
last := f
ensure
True
end
end
</e>
<e>
class
COW

inherit
ANIMAL
redefine all end

feature -- Access
last: GRASS

feature -- Eating
eat (f: variant like last) -- or eat (f: variant GRASS)
require else
True
-- 'f' type = expected type. Here: GRASS
do
-- 'f' type = type of the first definition. Here: FOOD
if attached f as expected then
-- 'expected' type = expected type. Here: GRASS
last := expected
end
ensure then
True
-- 'f' type = type of the first definition. Here: FOOD
end

end
</e>

'''example 2:''' covariant redefinition of feature argument with 'variant' typing on first feature definition.
<e>
class
ANIMAL

feature -- Access
last: FOOD

feature -- Eating
eat (f: variant like last)
do
if attached f as expected then
last := expected
end
end
end
</e>

<e>
class
COW

inherit
ANIMAL
redefine last end

feature -- Access
last: GRASS

end
</e>

=== Generic conformance ===
Default: a generic is novariant

If a genric must be variant (covariant or contravariant or both) then the formal generic must be prefixed with the 'variant' mark.

The compiler must ensure that the variant generic checks one next rule:
* Generic used only on feature argument is contravariant.
* Generic used only on request result or feature argument with variant typing is covariant.
* Generic not used is both contravariant and covariant.

'''The most restrictive type''' for a variant generic argument is the constrained inheritance type.
'''
example:'''
<e>
deferred class
EXAMPLE [variant K, variant G]
-- K is contravariant and G is covariant

feature -- Access
first: G

item (i: K): G
deferred
end

end
</e>

Therefore the next code is valid:
<e>
local
a: EXAMPLE [INTEGER, COMPARABLE]; b: EXAMPLE [NUMERIC, STRING]
do
-- ...
a := b
end
</e>

==== Agent conformance ====
As explained for [[Usage-site variance]] the generic 'OPEN_ARGS' from ROUTINE, PROCEDURE, FUNCTION, PREDICATE must be contravariant.

<e>
class
ROUTINE [BASE_TYPE, variant OPEN_ARGS -> detachable TUPLE create default_create end]
-- ...
end
</e>

The generic 'OPEN_ARGS' is used on feature arguments, but also on request result.

The class should probably be redesigned. Indeed if contravariant is allowed then there may be a new contravariant catcall on request result.

In these classes there are only two requests using the generic as type:
<e>
operands: detachable OPEN_ARGS

empty_operands: OPEN_ARGS
do create Result ensure ... end
</e>

The second request is not used internally and may be problematic for creation: How create a tuple of not self-initialized and attached types?
The first is used in these features : 'target', 'is_equal', 'set_operands', 'copy', 'apply'

'is_equal', 'set_operands' and 'copy' and 'target' rely on data model.
'apply' is more sensitive. Indeed the problem is when there is an opened target.

'apply' could be restricted for no opened arguments or could be removed since it is not a lot used.
<e>
apply
require
no_operands: open_count = 0
do
call (Void)
end
</e>

The redesign of agent classes is an opportunity to solve agent problems (see [[Minor-ECMA-problems]], [[Agents in SCOOP]]).

Another solution will be mentioned later.

Note:
The generic 'RESULT_TYPE' of FUNCTION class is used only on request result. Then it is a covariant generic. It is an expected point.

=== Comparison with other solutions ===
==== [[Detachable types]] (non-generic) ====
The variant typing is not in conflict with the void-safe typing.

And more the object test is not needed.

==== [[Usage-site variance]] (generic) ====
The variant typing is a supplier specification while usage-site variance is a client specification.

Another difference is the interface restriction of the usage-site variance. With the variant typing for generics the interface is fully aivailable.

=== Sub-conclusion ===
The limited variant typing is reasonable and expressive. It limits Eiffel changes and solves all catcall problems.

The proposal reuses an existing keyword.

The addition in TYPE class for reflexivity and dynamic object test is little.
Indeed two simple booleans "is_contravariant" and "is_covariant" for each generic is required.
<e>
generic_parameter_contravariant (i: INTEGER): BOOLEAN
-- Is `i'-th generic parameter contravariant?

generic_parameter_covariant (i: INTEGER): BOOLEAN
-- Is `i'-th generic parameter covariant?
</e>

A possible critical could be the generic conformance restriction. Propositions are mentioned below.

== General discussions ==
=== Greater flexibility for generics ===
A lot of generics could be novariant, encouraging to propose a solution to have a new flexibility, but safe.
==== Wildcard generics ====
The request result type is the constrained inheritance type. And the type of the feature argument is (attached) NONE.
The new semantic of 'Void' is considered: Void is not a NONE instance.

<e>
local
a: ARRAY [?]; b: ARRAY [STRING]
o: ANY
do
-- ...
a := b
o := a.item (1)
a.put ("try") -- invalid call. The type expected is NONE.
end
</e>

However the wildcard generics will be used on request result or feature argument. A more power and elegent solution could be the parametrized routines.

==== Parametrized routines ====
<e>
do_something [G] (a: ARRAY [G]): G
require
a.count >= 1
do
Result := a.item (1)
end
</e>

==== Right abstraction ====
The wildcard generics and the parametrized routines introduce new constructs for Eiffel. Is there another solution avoiding this?

With a right abstraction it is possible to have flexible classes. It is comparable to the imuutable cocncept.

'''example:''' V_CONTAINER class of Eiffel Base 2
To obtain the genric covariance behavior it is necessary to have:
* V_ITERATOR must have a covariant generic.
* TUPLE should be a read-only interface (V_MUTABLE_TUPLE would be the current TUPLE class). Therefore TUPLE could be conformed to V_SEQUENCE and V_MUTABLE_TUPLE conformed to V_ARRAY. Note that only the readonly interface could be in the Eiffel Standard.

In V_CONTAINER class only two features should use the variant typing:
<e>
new_cursor: V_ITERATOR [G]
do ... end

occurrences (v: variant G): INTEGER
do
-- G -> ANY then 'v' type = ANY
across Current as it loop
if it.item = v then
Result := Result + 1
end
end
end

has (v: variant G)
local
it: like new_cursor
do
-- G -> ANY then 'v' type = ANY
it := new_cursor -- 'it' type = V_ITERATOR [ANY]
it.search_forth (v)
Result := not it.after
ensure
occurrences (v) = 1
end
</e>

In V_ITERATOR only two features should use the variant typing without object test!

With these changes the next code is valid:
<e>
local
a: V_CONTAINER [ANY]; b: V_CONTAINER [STRING]
do
a := b

end
</e>

==== Sub-conclusion ====
With a right abstraction and a smart use of variant typing for generics, it is possible to obtain a greater flexibility keeping a fully aivailable interface.

=== Limit changes ===
To limit code change and to increase typing consistency, we can change the semantic of 'variant'.

Contravariant redefinition of request result is not very useful.
The variant typing could be limited for covariant redefinition. There could have no effect on request result.

For generic conformance, a formal generic prefixed with the variant mark is covariant. The variant mark is not required on feature argument limiting code change.

However we have a problem: How mark a contravariant generic? There is three options:
* Another mark.
* 'frozen' mark for novariant generic and then no mark for contravariant generic: too restrictive since novariance concerns a lot of generic classes
* No prefixed mark means novariant or contravariant generic

=== Export status restrictions ===
Since the ECMA Eiffel Standard forbids the export restriction with conforming inheritance, it is not a problem.
However, the semantic can be changed to enable this restriction on conforming inheritance.

Restrict exportation should not cause a catcall. The mechanism could be used just to change the class interface.
<e>
deferred class
ANIMAL
feature
is_vegetarian: BOOLEAN
deferred end
end
</e>
<e>
class
COW
inherit
ANIMAL
export {NONE}
is_vegetarian
end
feature {NONE}
is_vegetarian: BOOLEAN = True
end
</e>
<e>
local
an_animal: ANIMAL; a_cow: COW
b: BOOLEAN
do
create a_cow
b := a_cow.is_vegetarian -- invalid call

an_animal := a_cow
b := an_animal .is_vegetarian -- valid call
end
</e>

The class interface is more simple and readable.

== Conclusion ==
The proposition uses no new keyword and solves the catcall problem.
It passes all [[Catcall checkpoints]].

The new generic conformance gives a natural, safe, and flexible static typing.
The variant typing allows to create adaptive interfaces keeping a safe static typing.

With a fine abstraction and the use of variant typing for generics, the genric conformance flexibility is little restricted.

There is no interface restriction ([[Interval types]] or [[Usage-site variance]]). Class interfaces are fully available.

== Your view ==
name:
comment:

...

EiffelStudio Wish List

2014-05-05T21:25:25Z

Conaclos: Replace obsolete keyword with a simple note clause

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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:
<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>
|| || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.

A consequence is that expanded types are no longer generic creation ready.
Generic creation ready type could be frozen types with `default_create' as creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class PROPOSITION feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class CURRENT_STANDARD feature {NONE}
internal_something: A_TYPE
do end
end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).

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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

Default and explicit variance

2014-05-05T21:19:21Z

Conaclos: agent conformance update

[[Category:ECMA]]
[[Category:Catcall]]
{{Research}}
== Introduction ==
In first the limited variant typing is exposed. It checks all catcall checkpoints.
In the second part the mechanism is extended. It is less simple and explicit, but it enables a best transition.

== Limited variant typing ==
What is the advantages of covariance compared to a novariant typing?
* explicit and adaptative interface
* One routine

=== Variant typing ===
* A variant entity has '''the most restrictive type'''.
* A variant entity requires a simple object test to use the entity with the '''expected type'''.

Examples are available in next sections.

=== Feature redefinition ===
* Covariant redefinition of request result is allowed (as currently).
* Covariant redefinition of feature argument requires a variant typing on redefined argument or first definition.
'''The most restrictive type''' for a variant type argument is the type of the first definition.

The first rule is a stronger postcondition. The current semantic is not changed.

'''example 1:''' covariant redefinition of feature argument with 'variant' typing on redefined argument

Note:
* The object test is not needed.
* the type is not repeated in the object test.
* In the class interface the 'variant' is removed. Indeed, it is not possible to call 'eat' on an entity of type COW with a parameter of type FOOD.

<e>
class
ANIMAL

feature -- Access
last: FOOD

feature -- Eating
eat (f: like last)
require
True
do
last := f
ensure
True
end
end
</e>
<e>
class
COW

inherit
ANIMAL
redefine all end

feature -- Access
last: GRASS

feature -- Eating
eat (f: variant like last) -- or eat (f: variant GRASS)
require else
True
-- 'f' type = expected type. Here: GRASS
do
-- 'f' type = type of the first definition. Here: FOOD
if attached f as expected then
-- 'expected' type = expected type. Here: GRASS
last := expected
end
ensure then
True
-- 'f' type = type of the first definition. Here: FOOD
end

end
</e>

'''example 2:''' covariant redefinition of feature argument with 'variant' typing on first feature definition.
<e>
class
ANIMAL

feature -- Access
last: FOOD

feature -- Eating
eat (f: variant like last)
do
if attached f as expected then
last := expected
end
end
end
</e>

<e>
class
COW

inherit
ANIMAL
redefine last end

feature -- Access
last: GRASS

end
</e>

=== Generic conformance ===
Default: a generic is novariant

If a genric must be variant (covariant or contravariant or both) then the formal generic must be prefixed with the 'variant' mark.

The compiler must ensure that the variant generic checks one next rule:
* Generic used only on feature argument is contravariant.
* Generic used only on request result or feature argument with variant typing is covariant.
* Generic not used is both contravariant and covariant.

'''The most restrictive type''' for a variant generic argument is the constrained inheritance type.
'''
example:'''
<e>
deferred class
EXAMPLE [variant K, variant G]
-- K is contravariant and G is covariant

feature -- Access
first: G

item (i: K): G
deferred
end

end
</e>

Therefore the next code is valid:
<e>
local
a: EXAMPLE [INTEGER, COMPARABLE]; b: EXAMPLE [NUMERIC, STRING]
do
-- ...
a := b
end
</e>

==== Agent conformance ====
As explained for [[Usage-site variance]] the generic 'OPEN_ARGS' from ROUTINE, PROCEDURE, FUNCTION, PREDICATE must be contravariant.

<e>
class
ROUTINE [BASE_TYPE, variant OPEN_ARGS -> detachable TUPLE create default_create end]
-- ...
end
</e>

The generic 'OPEN_ARGS' is used on feature arguments, but also on request result.

The class should probably be redesigned. Indeed if contravariant is allowed then there may be a new contravariant catcall on request result.

In these classes there are only two requests using the generic as type:
<e>
operands: detachable OPEN_ARGS

empty_operands: OPEN_ARGS
do create Result ensure ... end
</e>

The second request is not used internally and may be problematic for creation: How create a tuple of not self-initialized and attached types?
The first is used in these features : 'target', 'is_equal', 'set_operands', 'copy', 'apply'

'is_equal', 'set_operands' and 'copy' and 'target' rely on data model.
'apply' is more sensitive. Indeed the problem is when there is an opened target.

'apply' could be restricted for no opened arguments or could be removed since it is not a lot used.
<e>
apply
require
no_operands: open_count = 0
do
call (Void)
end
</e>

The redesign of agent classes is an opportunity to solve agent problems (see [[Minor-ECMA-problems]], [[Agents in SCOOP]]).

Another solution will be mentioned later.

Note:
The generic 'RESULT_TYPE' of FUNCTION class is used only on request result. Then it is a covariant generic. It is an expected point.

=== Comparison with other solutions ===
==== [[Detachable types]] (non-generic) ====
The variant typing is not in conflict with the void-safe typing.

And more the object test is not needed.

==== [[Usage-site variance]] (generic) ====
The variant typing is a supplier specification while usage-site variance is a client specification.

Another difference is the interface restriction of the usage-site variance. With the variant typing for generics the interface is fully aivailable.

=== Sub-conclusion ===
The limited variant typing is reasonable and expressive. It limits Eiffel changes and solves all catcall problems.

The proposal reuses an existing keyword.

The addition in TYPE class for reflexivity and dynamic object test is little.
Indeed two simple booleans "is_contravariant" and "is_covariant" for each generic is required.
<e>
generic_parameter_contravariant (i: INTEGER): BOOLEAN
-- Is `i'-th generic parameter contravariant?

generic_parameter_covariant (i: INTEGER): BOOLEAN
-- Is `i'-th generic parameter covariant?
</e>

A possible critical could be the generic conformance restriction. Propositions are mentioned below.

== Extended variant typing ==
=== Generic conformance ===
The variant mark is optional. The compiler infers the generic variance. It is a good point for backward compatibility.

* Generic used only on feature argument or request result with variant typing is contravariant.

==== Agent conformance ====
It is possible to declare 'operands' and 'empty_operands' as variant.
<e>
operands: variant detachable OPEN_ARGS

empty_operands: variant OPEN_ARGS
do create Result ensure ... end
</e>

'apply' and 'target' should be wrote again. For example:
<e>
apply
do
-- 'operands' type = constrained inheritance. Here: detachable TUPLE
if attached operands as args then
-- 'operands' type = request result type. Here: OPEN_ARGS
call (args)
else
call (Void)
end
end
</e>

=== Sub-conclusion ===
This part extend the proposition to enable a best backward compatibility and then a best transition.

== General discussions ==
=== Greater flexibility for generics ===
A lot of generics could be novariant, encouraging to propose a solution to have a new flexibility, but safe.
==== Wildcard generics ====
The request result type is the constrained inheritance type. And the type of the feature argument is (attached) NONE.
The new semantic of 'Void' is considered: Void is not a NONE instance.

<e>
local
a: ARRAY [?]; b: ARRAY [STRING]
o: ANY
do
-- ...
a := b
o := a.item (1)
a.put ("try") -- invalid call. The type expected is NONE.
end
</e>

However the wildcard generics will be used on request result or feature argument. A more power and elegent solution could be the parametrized routines.

==== Parametrized routines ====
<e>
do_something [G] (a: ARRAY [G]): G
require
a.count >= 1
do
Result := a.item (1)
end
</e>

==== Right abstraction ====
The wildcard generics and the parametrized routines introduce new constructs for Eiffel. Is there another solution avoiding this?

With a right abstraction it is possible to have flexible classes. It is comparable to the imuutable cocncept.

'''example:''' V_CONTAINER class of Eiffel Base 2
To obtain the genric covariance behavior it is necessary to have:
* V_ITERATOR must have a covariant generic.
* TUPLE should be a read-only interface (V_MUTABLE_TUPLE would be the current TUPLE class). Therefore TUPLE could be conformed to V_SEQUENCE and V_MUTABLE_TUPLE conformed to V_ARRAY. Note that only the readonly interface could be in the Eiffel Standard.

In V_CONTAINER class only two features should use the variant typing:
<e>
new_cursor: V_ITERATOR [G]
do ... end

occurrences (v: variant G): INTEGER
do
-- G -> ANY then 'v' type = ANY
across Current as it loop
if it.item = v then
Result := Result + 1
end
end
end

has (v: variant G)
local
it: like new_cursor
do
-- G -> ANY then 'v' type = ANY
it := new_cursor -- 'it' type = V_ITERATOR [ANY]
it.search_forth (v)
Result := not it.after
ensure
occurrences (v) = 1
end
</e>

In V_ITERATOR only two features should use the variant typing without object test!

With these changes the next code is valid:
<e>
local
a: V_CONTAINER [ANY]; b: V_CONTAINER [STRING]
do
a := b

end
</e>

==== Sub-conclusion ====
With a right abstraction and a smart use of variant typing for generics, it is possible to obtain a greater flexibility keeping a fully aivailable interface.

=== Limit changes ===
To limit code change and to increase typing consistency, we can change the semantic of 'variant'.

Contravariant redefinition of request result is not very useful.
The variant typing could be limited for covariant redefinition. There could have no effect on request result.

For generic conformance, a formal generic prefixed with the variant mark is covariant. The variant mark is not required on feature argument limiting code change.

However we have a problem: How mark a contravariant generic? There is three options:
* Another mark.
* 'frozen' mark for novariant generic and then no mark for contravariant generic: too restrictive since novariance concerns a lot of generic classes
* No prefixed mark means novariant or contravariant generic

=== Export status restrictions ===
Since the ECMA Eiffel Standard forbids the export restriction with conforming inheritance, it is not a problem.
However, the semantic can be changed to enable this restriction on conforming inheritance.

Restrict exportation should not cause a catcall. The mechanism could be used just to change the class interface.
<e>
deferred class
ANIMAL
feature
is_vegetarian: BOOLEAN
deferred end
end
</e>
<e>
class
COW
inherit
ANIMAL
export {NONE}
is_vegetarian
end
feature {NONE}
is_vegetarian: BOOLEAN = True
end
</e>
<e>
local
an_animal: ANIMAL; a_cow: COW
b: BOOLEAN
do
create a_cow
b := a_cow.is_vegetarian -- invalid call

an_animal := a_cow
b := an_animal .is_vegetarian -- valid call
end
</e>

The class interface is more simple and readable.

== Conclusion ==
The proposition uses no new keyword and solves the catcall problem.
It passes all [[Catcall checkpoints]].

The new generic conformance gives a natural safe and flexible static typing.
The variant typing enables to create adaptive interfaces keeping a safe static typing.

With a fine abstraction and the use of variant typing for generics, the genric conformance flexibility is little restricted. The contravariant for request result can then be discarded for simplicity.

There is no interface restriction ([[Interval types]] or [[Usage-site variance]]). Class interfaces are fully available.

== Your view ==
name:
comment:

...

EiffelStudio Wish List

2014-05-03T22:31:04Z

Conaclos: Adding a consequence of customized creation procedure for expanded type

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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:
<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>
|| || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.

A consequence is that expanded types are no longer generic creation ready.
Generic creation ready type could be frozen types with `default_create' as creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).

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

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-05-03T22:25:50Z

Conaclos: Adding precision for note inheritance

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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:
<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>
|| || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).

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

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-05-03T22:19:43Z

Conaclos: Put redefine correction proposal in the correct 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.

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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:
<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>
|| || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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' clause is inherited if it is not redefined.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-04-28T21:27:13Z

Conaclos: Adding precision

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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. || || ||

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

|}

== IDE ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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' clause is inherited if it is not redefined.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-04-28T21:25:52Z

Conaclos: Fix genral layout

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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. || || ||

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

|}

== IDE ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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 (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>
|| || ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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' clause is inherited if it is not redefined.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-04-28T21:25:08Z

Conaclos: Fix layout issue

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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. || || ||

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

|}

== IDE ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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 (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>
|| || ||

}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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' clause is inherited if it is not redefined.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-04-28T21:23:21Z

Conaclos: /* IDE */

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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. || || ||

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

|}

== IDE ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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 (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>
|

||||

}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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' clause is inherited if it is not redefined.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-04-21T14:09:58Z

Conaclos: Note clause and inheritance

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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. || || ||

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

|}

== IDE ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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

|
||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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' clause is inherited if it is not redefined.
Since a feature documentation is a part of the note clause (`what' tag),
it is also inherited (simple <e>-- <Precursor></e> is not longer required).
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-04-21T13:40:57Z

Conaclos: Conditional expression without `else' branch

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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. || || ||

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

|}

== IDE ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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

|
||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

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

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-04-21T13:31:56Z

Conaclos: More strict semantic for `require else' and `ensure then'

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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. || || ||

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

|}

== IDE ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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

|
||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

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

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-04-21T13:25:25Z

Conaclos: Make `redefine' ECMA conform

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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. || || ||

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

|}

== IDE ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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

|
||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

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

|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-04-21T12:47:41Z

Conaclos: documentation checker and Inspector Eiffel

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<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

|
||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

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

|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2014-04-21T12:45:00Z

Conaclos: CHange proposal for creation procedure for expanded type

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<e>
apply
-- Call procedure with `args' as last set.
do
call (operands)
end
</e>
Throws a warning for nonexistent `args' feature.
|Help to maintain an updated documentation

|
||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

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

|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

Default and explicit variance

2014-03-03T17:10:59Z

Conaclos: ARgument and feature ambiguity solved

[[Category:ECMA]]
[[Category:Catcall]]
{{Research}}
== Introduction ==
In first the limited variant typing is exposed. It checks all catcall checkpoints.
In the second part the mechanism is extended. It is less simple and explicit, but it enables a best transition.

== Limited variant typing ==
What is the advantages of covariance compared to a novariant typing?
* explicit and adaptative interface
* One routine

=== Variant typing ===
* A variant entity has '''the most restrictive type'''.
* A variant entity requires a simple object test to use the entity with the '''expected type'''.

Examples are available in next sections.

=== Feature redefinition ===
* Covariant redefinition of request result is allowed (as currently).
* Covariant redefinition of feature argument requires a variant typing on redefined argument or first definition.
'''The most restrictive type''' for a variant type argument is the type of the first definition.

The first rule is a stronger postcondition. The current semantic is not changed.

'''example 1:''' covariant redefinition of feature argument with 'variant' typing on redefined argument

Note:
* The object test is not needed.
* the type is not repeated in the object test.
* In the class interface the 'variant' is removed. Indeed, it is not possible to call 'eat' on an entity of type COW with a parameter of type FOOD.

<e>
class
ANIMAL

feature -- Access
last: FOOD

feature -- Eating
eat (f: like last)
require
True
do
last := f
ensure
True
end
end
</e>
<e>
class
COW

inherit
ANIMAL
redefine all end

feature -- Access
last: GRASS

feature -- Eating
eat (f: variant like last) -- or eat (f: variant GRASS)
require else
True
-- 'f' type = expected type. Here: GRASS
do
-- 'f' type = type of the first definition. Here: FOOD
if attached f as expected then
-- 'expected' type = expected type. Here: GRASS
last := expected
end
ensure then
True
-- 'f' type = type of the first definition. Here: FOOD
end

end
</e>

'''example 2:''' covariant redefinition of feature argument with 'variant' typing on first feature definition.
<e>
class
ANIMAL

feature -- Access
last: FOOD

feature -- Eating
eat (f: variant like last)
do
if attached f as expected then
last := expected
end
end
end
</e>

<e>
class
COW

inherit
ANIMAL
redefine last end

feature -- Access
last: GRASS

end
</e>

=== Generic conformance ===
Default: a generic is novariant

If a genric must be variant (covariant or contravariant or both) then the formal generic must be prefixed with the 'variant' mark.

The compiler must ensure that the variant generic checks one next rule:
* Generic used only on feature argument is contravariant.
* Generic used only on request result or feature argument with variant typing is covariant.
* Generic not used is both contravariant and covariant.

'''The most restrictive type''' for a variant generic argument is the constrained inheritance type.
'''
example:'''
<e>
deferred class
EXAMPLE [variant K, variant G]
-- K is contravariant and G is covariant

feature -- Access
first: G

item (i: K): G
deferred
end

end
</e>

Therefore the next code is valid:
<e>
local
a: EXAMPLE [INTEGER, COMPARABLE]; b: EXAMPLE [NUMERIC, STRING]
do
-- ...
a := b
end
</e>

==== Agent conformance ====
As explained for [[Usage-site variance]] the generic 'OPEN_ARGS' from ROUTINE, PROCEDURE, FUNCTION, PREDICATE must be contravariant.

<e>
class
ROUTINE [BASE_TYPE, variant OPEN_ARGS -> detachable TUPLE create default_create end]
-- ...
end
</e>

The generic 'OPEN_ARGS' is used on feature arguments, but also on request result.

The class should probably be redesigned. Indeed if contravariant is allowed then there may be a new contravariant catcall on request result.

In these classes there are only two requests using the generic as type:
<e>
operands: detachable OPEN_ARGS

empty_operands: OPEN_ARGS
do create Result ensure ... end
</e>

The second request is not used internally and may be problematic for creation: How create a tuple of not self-initialized and attached types?
The first is used in these features : 'target', 'is_equal', 'set_operands', 'copy', 'apply'

'is_equal', 'set_operands' and 'copy' rely on data model.
'apply' and 'target' are more sensitive. Indeed the problem is when there is an opened target.

'apply' could be restricted for no opened arguments.
<e>
apply
require
no_operands: open_count = 0
do
call (Void)
end
</e>
'target' could be modfied:
<e>
target: ANY
require
is_target_closed
do
-- ...
end
</e>

Or maybe it is better to separate opened target and closed target in two abstractions.

The redesign of agent classes is an opportunity to solve agent problems (see [[Minor-ECMA-problems]], [[Agents in SCOOP]]).

Another solution will be mentioned later.

Note:
The generic 'RESULT_TYPE' of FUNCTION class is used only on request result. Then it is a covariant generic. It is an expected point.

=== Comparison with other solutions ===
==== [[Detachable types]] (non-generic) ====
The variant typing is not in conflict with the void-safe typing.

And more the object test is not needed.

==== [[Usage-site variance]] (generic) ====
The variant typing is a supplier specification while usage-site variance is a client specification.

Another difference is the interface restriction of the usage-site variance. With the variant typing for generics the interface is fully aivailable.

=== Sub-conclusion ===
The limited variant typing is reasonable and expressive. It limits Eiffel changes and solves all catcall problems.

The proposal reuses an existing keyword.

The addition in TYPE class for reflexivity and dynamic object test is little.
Indeed two simple booleans "is_contravariant" and "is_covariant" for each generic is required.
<e>
generic_parameter_contravariant (i: INTEGER): BOOLEAN
-- Is `i'-th generic parameter contravariant?

generic_parameter_covariant (i: INTEGER): BOOLEAN
-- Is `i'-th generic parameter covariant?
</e>

A possible critical could be the generic conformance restriction. Propositions are mentioned below.

== Extended variant typing ==
=== Generic conformance ===
The variant mark is optional. The compiler infers the generic variance. It is a good point for backward compatibility.

* Generic used only on feature argument or request result with variant typing is contravariant.

==== Agent conformance ====
It is possible to declare 'operands' and 'empty_operands' as variant.
<e>
operands: variant detachable OPEN_ARGS

empty_operands: variant OPEN_ARGS
do create Result ensure ... end
</e>

'apply' and 'target' should be wrote again. For example:
<e>
apply
do
-- 'operands' type = constrained inheritance. Here: detachable TUPLE
if attached operands as args then
-- 'operands' type = request result type. Here: OPEN_ARGS
call (args)
else
call (Void)
end
end
</e>

=== Sub-conclusion ===
This part extend the proposition to enable a best backward compatibility and then a best transition.

== General discussions ==
=== Greater flexibility for generics ===
A lot of generics could be novariant, encouraging to propose a solution to have a new flexibility, but safe.
==== Wildcard generics ====
The request result type is the constrained inheritance type. And the type of the feature argument is (attached) NONE.
The new semantic of 'Void' is considered: Void is not a NONE instance.

<e>
local
a: ARRAY [?]; b: ARRAY [STRING]
o: ANY
do
-- ...
a := b
o := a.item (1)
a.put ("try") -- invalid call. The type expected is NONE.
end
</e>

However the wildcard generics will be used on request result or feature argument. A more power and elegent solution could be the parametrized routines.

==== Parametrized routines ====
<e>
do_something [G] (a: ARRAY [G]): G
require
a.count >= 1
do
Result := a.item (1)
end
</e>

==== Right abstraction ====
The wildcard generics and the parametrized routines introduce new constructs for Eiffel. Is there another solution avoiding this?

With a right abstraction it is possible to have flexible classes. It is comparable to the imuutable cocncept.

'''example:''' V_CONTAINER class of Eiffel Base 2
To obtain the genric covariance behavior it is necessary to have:
* V_ITERATOR must have a covariant generic.
* TUPLE should be a read-only interface (V_MUTABLE_TUPLE would be the current TUPLE class). Therefore TUPLE could be conformed to V_SEQUENCE and V_MUTABLE_TUPLE conformed to V_ARRAY. Note that only the readonly interface could be in the Eiffel Standard.

In V_CONTAINER class only two features should use the variant typing:
<e>
new_cursor: V_ITERATOR [G]
do ... end

occurrences (v: variant G): INTEGER
do
-- G -> ANY then 'v' type = ANY
across Current as it loop
if it.item = v then
Result := Result + 1
end
end
end

has (v: variant G)
local
it: like new_cursor
do
-- G -> ANY then 'v' type = ANY
it := new_cursor -- 'it' type = V_ITERATOR [ANY]
it.search_forth (v)
Result := not it.after
ensure
occurrences (v) = 1
end
</e>

In V_ITERATOR only two features should use the variant typing without object test!

With these changes the next code is valid:
<e>
local
a: V_CONTAINER [ANY]; b: V_CONTAINER [STRING]
do
a := b

end
</e>

==== Sub-conclusion ====
With a right abstraction and a smart use of variant typing for generics, it is possible to obtain a greater flexibility keeping a fully aivailable interface.

=== Limit changes ===
To limit code change and to increase typing consistency, we can change the semantic of 'variant'.

Contravariant redefinition of request result is not very useful.
The variant typing could be limited for covariant redefinition. There could have no effect on request result.

For generic conformance, a formal generic prefixed with the variant mark is covariant. The variant mark is not required on feature argument limiting code change.

However we have a problem: How mark a contravariant generic? There is three options:
* Another mark.
* 'frozen' mark for novariant generic and then no mark for contravariant generic: too restrictive since novariance concerns a lot of generic classes
* No prefixed mark means novariant or contravariant generic

=== Export status restrictions ===
Since the ECMA Eiffel Standard forbids the export restriction with conforming inheritance, it is not a problem.
However, the semantic can be changed to enable this restriction on conforming inheritance.

Restrict exportation should not cause a catcall. The mechanism could be used just to change the class interface.
<e>
deferred class
ANIMAL
feature
is_vegetarian: BOOLEAN
deferred end
end
</e>
<e>
class
COW
inherit
ANIMAL
export {NONE}
is_vegetarian
end
feature {NONE}
is_vegetarian: BOOLEAN = True
end
</e>
<e>
local
an_animal: ANIMAL; a_cow: COW
b: BOOLEAN
do
create a_cow
b := a_cow.is_vegetarian -- invalid call

an_animal := a_cow
b := an_animal .is_vegetarian -- valid call
end
</e>

The class interface is more simple and readable.

== Conclusion ==
The proposition uses no new keyword and solves the catcall problem.
It passes all [[Catcall checkpoints]].

The new generic conformance gives a natural safe and flexible static typing.
The variant typing enables to create adaptive interfaces keeping a safe static typing.

With a fine abstraction and the use of variant typing for generics, the genric conformance flexibility is little restricted. The contravariant for request result can then be discarded for simplicity.

There is no interface restriction ([[Interval types]] or [[Usage-site variance]]). Class interfaces are fully available.

== Your view ==
name:
comment:

...

EiffelStudio Wish List

2014-02-01T22:55:26Z

Conaclos: Updated documentation checker

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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:
<e>
apply
-- Call procedure with `args' as last set.
do
call (operands)
end
</e>
Throws a warning for nonexistent `args' feature.
|Help to maintain an updated documentation

|
||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

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

|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

Agent Calls

2014-02-01T18:46:34Z

Conaclos: Object test

[[Category:Compiler]]
[[Category:Code Generation]]
{{Warning|Article under development}}

====Introduction====
The Eiffel programming language supports closures with agents. As a reminder, an agent is a normal Eiffel object of one of the types:
*FUNCTION
*PROCEDURE
Some terminology is needed: The place where an agent is created (with the agent keyword or the tilde operator) is called the '''agent creation'''. The feature to which the agent points is the '''agent callee''' and the place (or places) where the agent is called is denoted '''agent call'''.

An example that clarifies these terms:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<code>[eiffel,N]class
TERMINOLOGY

feature

f1
local
p: PROCEDURE [ANY, TUPLE]
do
p := agent target -- agent creation
end

f2 (p: PROCEDURE [ANY, TUPLE])
do
p.call ([]) -- agent call
end

target -- callee
do
end
end</code>
|
|}

====The problem====
It is again helpful to focus on the differences between the Eiffel and C language. Eiffel supports closures, C only supports function pointers. A way is needed thus to construct closures based on function pointers. Dynamic binding also contributes its part to the problem. It is not known at compile time which exact feature an agent (when looking at its '''agent creation''') refers to. But it gets even worse, sometimes the feature is not known until the agent is called (at runtime). This is the case for agents with open targets.
====The data structure====
Class C will be used for the following examples:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<code>[eiffel,N]class
C

feature
f (p1, p2: INTEGER; p3: STRING): STRING
do
...
end
end</code>
|
|}

There are three data structures needed for an agent:
* The open_map (member of class ROUTINE)
* The closed_operands (member of class ROUTINE)
* The open_operands
The open_map is known at compile time when an '''agent_creation''' is detected. The closed_operands are known at '''agent creation''' time. The open_operands are not known until the agent is called.

The content of these structures will be given for agent one and two:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
! Agent one !! Agent two
|-
|
<code>[eiffel, N]
agent c.f (?, 1, ?)
</code>
|
<code>[eiffel, N]
agent {C}.f (1, ?, "hello")
</code>
|}

The open_map is an array that has an entry for every open parameter. Its content for agents one and two are:
#{2,4}
#{1,3}
The closed_operands is a TUPLE that has an entry for every closed operand. Its content for agents one and two again:
#{c, 1}
#{1, "hello"}

====The wrapper====
It comes by no surprise that the compiler creates special wrapper functions for agents. It is interesting though that these wrappers are created per '''agent creation'''. This has the advantage that it is known whether a given formal argument is open or closed.

In workbench mode, for every '''agent creation''' a C-function is generated. This wrapper function does the following:
*Arrange the closed and open arguments in the right order.
*Calculate the proper '''agent callee''' based on the dynamic type of the target.
*Call the '''agent callee'''.

For the '''agent creation''':
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<code>[eiffel, N]
agent c.f (?, 1, ?)
</code>
|
|}
the following wrapper function is generated:
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|<code>[c, N]EIF_REFERENCE _fAaatpmf_2_4 (
EIF_REFERENCE (*f_ptr)(EIF_REFERENCE, //can be ignored
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE),
EIF_TYPED_ELEMENT* closed, //Closed arguments
EIF_TYPED_ELEMENT* open) //Open arguments
{
return
(FUNCTION_CAST(EIF_REFERENCE, (EIF_REFERENCE,
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE))
//Dynamic binding using the target:
RTVF(350, 30, "f", closed [1].element.rarg))(
//Arranging the open and closed arguments:
closed [1].element.rarg,
open [1].element.i32arg,
closed [2].element.i32arg,
open [2].element.rarg);
}
</code>
|
|}
This example shows how the wrapper does its three tasks. The suffix "_2_4" of the wrapper comes from the fact that the second and forth parameter (first and third argument) are open.

A second example is given:
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|<code>[eiffel, N]
agent {C}.f (1, ?, "hello")
</code>
|}
For this '''agent creation''' the wrapper function looks like:
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|<code>[c, N]
EIF_REFERENCE _fAaatpmf_1_3 (
EIF_REFERENCE (*f_ptr)(EIF_REFERENCE, //can be ignored
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE),
EIF_TYPED_ELEMENT* closed, //Closed arguments
EIF_TYPED_ELEMENT* open) //Open arguments
{
return
(FUNCTION_CAST(EIF_REFERENCE, (EIF_REFERENCE,
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE))
//Dynamic binding using the target:
RTVF(350, 30, "f", open [1].element.rarg))(
//Arranging the open and closed arguments:
open [1].element.rarg,
closed [1].element.i32arg,
open [2].element.i32arg,
closed [2].element.rarg);
}
</code>
|}
This time the suffix is "_1_3" since the first and third parameter (target and second argument) are open.

====Agent call====
An '''agent call''' like the following:
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<eiffel>
local
f: FUNCTION [ANY, TUPLE [INTEGER], INTEGER]
b: BOOLEAN
do
b := f.item ([10])
end
</eiffel>
|
|}
Obviously calls feature <eiffel>item</eiffel> of class <eiffel>FUNCTION</eiffel>:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<eiffel>
item (args: OPEN_ARGS): RESULT_TYPE is
-- Result of calling function with `args' as operands.
require
valid_operands: valid_operands (args)
local
l_closed_count: INTEGER
do
l_closed_count := closed_operands.count
Result := fast_item (encaps_rout_disp, calc_rout_addr,
$closed_operands, $args, class_id, feature_id,
is_precompiled, is_basic, is_inline_agent,
l_closed_count, open_count, $open_map)
end
</eiffel>
|
|}

This leads to a call to the external C feature <eiffel>fast_item</eiffel> of class <eiffel>FUNCTION</eiffel>:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<eiffel>fast_item (a_rout_disp, a_calc_rout_addr: POINTER
a_closed_operands: POINTER; a_operands: POINTER
a_class_id, a_feature_id: INTEGER
a_is_precompiled, a_is_basic, a_is_inline_agent: BOOLEAN
a_closed_count, a_open_count: INTEGER; a_open_map: POINTER): RESULT_TYPE
external
"C inline use %"eif_rout_obj.h%""
alias
"[
#ifdef WORKBENCH
$$_result_type result;
if ($a_rout_disp != 0) {
return (FUNCTION_CAST($$_result_type,
(EIF_POINTER, EIF_REFERENCE, EIF_REFERENCE)) $a_rout_disp)(
$a_calc_rout_addr, $a_closed_operands, $a_operands);
} else {
...
}
#else
...
#endif
]"
end</eiffel>
|
|}

When there is a valid function pointer to the wrapper (<c>a_rout_disp != 0</c>) it is called with the closed and open operands as parameters. The wrapper will then call the actual '''agent callee'''. The case when there is no valid function pointer will be considered later.

====Improving the dynamic binding====
When at '''agent creation''' the target is closed, the exact '''agent callee''' can be calculated at '''agent creation'''. This improves performance when the agent is called more than once. This optimization is only done when in final mode.

====Eradicating manifest tuple creation====
In finalized mode there is a simple optimization that speeds things up significantly. It is not uncommon, that an '''agent calls''' passes a manifest tuple as parameter, see the following call:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<eiffel>
b := f.item ([10, 20, "hello"])
</eiffel>
|
|}

The lifetime of this tuple is short. It is only used throughout the call to <eiffel>item</eiffel>. Tuple creations are not that fast, they take several times longer than the '''agent call''' itself. Thats why the EiffelStudio in finalized mode replaces these calls to <eiffel>item</eiffel> by a direct call to wrapper function. If the open parameters in Eiffel code are passed in the form of a manifest tuple, they are directly passed to the wrapper function in the translated code, to get rid of the slow tuple creation.

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<c>
tp1 = RTMS_EX_H("hello",5,1702403183);
tp2 = tp1;
tp1 = (FUNCTION_CAST(EIF_REFERENCE, (EIF_POINTER,
EIF_REFERENCE,
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE))
*(EIF_POINTER *)(loc3+ @PTROFF(5,4,0,3,0,0)))( //calling the wrapper function
*(EIF_POINTER *)(loc3+ @PTROFF(5,4,0,3,0,1)), //passing the calculated agent callee
*(EIF_REFERENCE *)(loc3 + @REFACS(1)), //passing the closed parameters
((EIF_INTEGER_32) 10L), //passing 10
((EIF_INTEGER_32) 11L), //passing 11
tp2); //passing "hello"
</c>
|
|}

====Wrapper functions in final mode====
Due to the potential optimization described above, in final mode two C wrapper functions are generated:
*one which expects the closed arguments as a tuple (encapsulated). The only difference to the frozen wrapper is how the '''agent callee''' is calculated.
*and one that expects them as separate parameters.

For the '''agent creation''':
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<eiffel>
agent c.f (?, 1, ?)
</eiffel>
|}
the following wrapper functions are generated:
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<c>
EIF_REFERENCE _fAaatpmf_2_4 (
EIF_REFERENCE (*f_ptr)(EIF_REFERENCE,
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE),
EIF_TYPED_ELEMENT* closed,
EIF_TYPED_ELEMENT* open)
{
return f_ptr (closed [1].element.rarg,
open [1].element.i32arg,
closed [2].element.i32arg,
open [2].element.rarg);
}
</c>
|
<c>
EIF_REFERENCE __fAaatpmf_2_4 (
EIF_REFERENCE (*f_ptr)(EIF_REFERENCE,
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE),
EIF_TYPED_ELEMENT* closed,
EIF_INTEGER_32 op_2,
EIF_REFERENCE op_4)
{
return f_ptr (closed [1].element.rarg,
op_2,
closed [2].element.i32arg,
op_4);
}
</c>
|}
The name of the wrapper for the encapsulated closed arguments always starts with one '_', whereas the other one starts with two underlines.

====Melted agent creator====
Of course it is possible that the '''agent creation''' is melted and hence there is no wrapper. For this situation the Eiffel runtime provides two generic wrapper functions:

<code>[c, N]
RT_LNK void rout_obj_call_procedure_dynamic (
int stype_id, int feature_id, int is_precompiled, int is_basic_type, int is_inline_agent, EIF_TYPED_ELEMENT* closed_args,
int closed_count, EIF_TYPED_ELEMENT* open_args, int open_count, EIF_REFERENCE open_map);

RT_LNK void rout_obj_call_function_dynamic (
int stype_id, int feature_id, int is_precompiled, int is_basic_type, int is_inline_agent, EIF_TYPED_ELEMENT* closed_args,
int closed_count, EIF_TYPED_ELEMENT* open_args, int open_count, EIF_REFERENCE open_map, void* res);
</code>

These functions calculate the '''agent callee''' with the static type id and a feature id. Furthermore the reordering of open and closed arguments has to be done at agent call time with help of the open_map.

== Strategy for optimizing dotnet Agent Calls ==
Work in progress!
Compared to the Classic version, dotnet Agent Calls are slow. The a short look at feature apply of class FUNCTION shows why:

<e>
apply
-- Call function with `operands' as last set.
do
if attached {RESULT_TYPE} rout_disp.invoke (target_object, internal_operands) as al_last_result then
last_result := al_last_result
end
end
</e>

The actual call is done through reflection. Additionally, in dotnet the two major optimizations are missing:

*Directly passing the elements of manifest tuples as parameters. (And hence not creating the tuple)
*Computing the reordering of closed and open operands at compile time. (By generating the proper wrapper)

All these three issues can be removed.

For every '''agent creation''' we create:
* A delegate type that requires two Tuples (closed and open arguments) as arguments.
* A static method that conforms to this delegate type. This method does the ordering of closed and open arguments and calls the '''agent callee'''.
* A second delegate type, that requires one Tuple (closed arguments) and all the open arguments as arguments.
* A second static method which conforms to the second delegate type and does the ordering and '''agent callee''' call.

Agent Calls

2014-02-01T18:44:55Z

Conaclos: Replace obsolete syntax

[[Category:Compiler]]
[[Category:Code Generation]]
{{Warning|Article under development}}

====Introduction====
The Eiffel programming language supports closures with agents. As a reminder, an agent is a normal Eiffel object of one of the types:
*FUNCTION
*PROCEDURE
Some terminology is needed: The place where an agent is created (with the agent keyword or the tilde operator) is called the '''agent creation'''. The feature to which the agent points is the '''agent callee''' and the place (or places) where the agent is called is denoted '''agent call'''.

An example that clarifies these terms:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<code>[eiffel,N]class
TERMINOLOGY

feature

f1
local
p: PROCEDURE [ANY, TUPLE]
do
p := agent target -- agent creation
end

f2 (p: PROCEDURE [ANY, TUPLE])
do
p.call ([]) -- agent call
end

target -- callee
do
end
end</code>
|
|}

====The problem====
It is again helpful to focus on the differences between the Eiffel and C language. Eiffel supports closures, C only supports function pointers. A way is needed thus to construct closures based on function pointers. Dynamic binding also contributes its part to the problem. It is not known at compile time which exact feature an agent (when looking at its '''agent creation''') refers to. But it gets even worse, sometimes the feature is not known until the agent is called (at runtime). This is the case for agents with open targets.
====The data structure====
Class C will be used for the following examples:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<code>[eiffel,N]class
C

feature
f (p1, p2: INTEGER; p3: STRING): STRING
do
...
end
end</code>
|
|}

There are three data structures needed for an agent:
* The open_map (member of class ROUTINE)
* The closed_operands (member of class ROUTINE)
* The open_operands
The open_map is known at compile time when an '''agent_creation''' is detected. The closed_operands are known at '''agent creation''' time. The open_operands are not known until the agent is called.

The content of these structures will be given for agent one and two:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
! Agent one !! Agent two
|-
|
<code>[eiffel, N]
agent c.f (?, 1, ?)
</code>
|
<code>[eiffel, N]
agent {C}.f (1, ?, "hello")
</code>
|}

The open_map is an array that has an entry for every open parameter. Its content for agents one and two are:
#{2,4}
#{1,3}
The closed_operands is a TUPLE that has an entry for every closed operand. Its content for agents one and two again:
#{c, 1}
#{1, "hello"}

====The wrapper====
It comes by no surprise that the compiler creates special wrapper functions for agents. It is interesting though that these wrappers are created per '''agent creation'''. This has the advantage that it is known whether a given formal argument is open or closed.

In workbench mode, for every '''agent creation''' a C-function is generated. This wrapper function does the following:
*Arrange the closed and open arguments in the right order.
*Calculate the proper '''agent callee''' based on the dynamic type of the target.
*Call the '''agent callee'''.

For the '''agent creation''':
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<code>[eiffel, N]
agent c.f (?, 1, ?)
</code>
|
|}
the following wrapper function is generated:
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|<code>[c, N]EIF_REFERENCE _fAaatpmf_2_4 (
EIF_REFERENCE (*f_ptr)(EIF_REFERENCE, //can be ignored
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE),
EIF_TYPED_ELEMENT* closed, //Closed arguments
EIF_TYPED_ELEMENT* open) //Open arguments
{
return
(FUNCTION_CAST(EIF_REFERENCE, (EIF_REFERENCE,
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE))
//Dynamic binding using the target:
RTVF(350, 30, "f", closed [1].element.rarg))(
//Arranging the open and closed arguments:
closed [1].element.rarg,
open [1].element.i32arg,
closed [2].element.i32arg,
open [2].element.rarg);
}
</code>
|
|}
This example shows how the wrapper does its three tasks. The suffix "_2_4" of the wrapper comes from the fact that the second and forth parameter (first and third argument) are open.

A second example is given:
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|<code>[eiffel, N]
agent {C}.f (1, ?, "hello")
</code>
|}
For this '''agent creation''' the wrapper function looks like:
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|<code>[c, N]
EIF_REFERENCE _fAaatpmf_1_3 (
EIF_REFERENCE (*f_ptr)(EIF_REFERENCE, //can be ignored
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE),
EIF_TYPED_ELEMENT* closed, //Closed arguments
EIF_TYPED_ELEMENT* open) //Open arguments
{
return
(FUNCTION_CAST(EIF_REFERENCE, (EIF_REFERENCE,
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE))
//Dynamic binding using the target:
RTVF(350, 30, "f", open [1].element.rarg))(
//Arranging the open and closed arguments:
open [1].element.rarg,
closed [1].element.i32arg,
open [2].element.i32arg,
closed [2].element.rarg);
}
</code>
|}
This time the suffix is "_1_3" since the first and third parameter (target and second argument) are open.

====Agent call====
An '''agent call''' like the following:
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<eiffel>
local
f: FUNCTION [ANY, TUPLE [INTEGER], INTEGER]
b: BOOLEAN
do
b := f.item ([10])
end
</eiffel>
|
|}
Obviously calls feature <eiffel>item</eiffel> of class <eiffel>FUNCTION</eiffel>:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<eiffel>
item (args: OPEN_ARGS): RESULT_TYPE is
-- Result of calling function with `args' as operands.
require
valid_operands: valid_operands (args)
local
l_closed_count: INTEGER
do
l_closed_count := closed_operands.count
Result := fast_item (encaps_rout_disp, calc_rout_addr,
$closed_operands, $args, class_id, feature_id,
is_precompiled, is_basic, is_inline_agent,
l_closed_count, open_count, $open_map)
end
</eiffel>
|
|}

This leads to a call to the external C feature <eiffel>fast_item</eiffel> of class <eiffel>FUNCTION</eiffel>:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<eiffel>fast_item (a_rout_disp, a_calc_rout_addr: POINTER
a_closed_operands: POINTER; a_operands: POINTER
a_class_id, a_feature_id: INTEGER
a_is_precompiled, a_is_basic, a_is_inline_agent: BOOLEAN
a_closed_count, a_open_count: INTEGER; a_open_map: POINTER): RESULT_TYPE
external
"C inline use %"eif_rout_obj.h%""
alias
"[
#ifdef WORKBENCH
$$_result_type result;
if ($a_rout_disp != 0) {
return (FUNCTION_CAST($$_result_type,
(EIF_POINTER, EIF_REFERENCE, EIF_REFERENCE)) $a_rout_disp)(
$a_calc_rout_addr, $a_closed_operands, $a_operands);
} else {
...
}
#else
...
#endif
]"
end</eiffel>
|
|}

When there is a valid function pointer to the wrapper (<c>a_rout_disp != 0</c>) it is called with the closed and open operands as parameters. The wrapper will then call the actual '''agent callee'''. The case when there is no valid function pointer will be considered later.

====Improving the dynamic binding====
When at '''agent creation''' the target is closed, the exact '''agent callee''' can be calculated at '''agent creation'''. This improves performance when the agent is called more than once. This optimization is only done when in final mode.

====Eradicating manifest tuple creation====
In finalized mode there is a simple optimization that speeds things up significantly. It is not uncommon, that an '''agent calls''' passes a manifest tuple as parameter, see the following call:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<eiffel>
b := f.item ([10, 20, "hello"])
</eiffel>
|
|}

The lifetime of this tuple is short. It is only used throughout the call to <eiffel>item</eiffel>. Tuple creations are not that fast, they take several times longer than the '''agent call''' itself. Thats why the EiffelStudio in finalized mode replaces these calls to <eiffel>item</eiffel> by a direct call to wrapper function. If the open parameters in Eiffel code are passed in the form of a manifest tuple, they are directly passed to the wrapper function in the translated code, to get rid of the slow tuple creation.

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<c>
tp1 = RTMS_EX_H("hello",5,1702403183);
tp2 = tp1;
tp1 = (FUNCTION_CAST(EIF_REFERENCE, (EIF_POINTER,
EIF_REFERENCE,
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE))
*(EIF_POINTER *)(loc3+ @PTROFF(5,4,0,3,0,0)))( //calling the wrapper function
*(EIF_POINTER *)(loc3+ @PTROFF(5,4,0,3,0,1)), //passing the calculated agent callee
*(EIF_REFERENCE *)(loc3 + @REFACS(1)), //passing the closed parameters
((EIF_INTEGER_32) 10L), //passing 10
((EIF_INTEGER_32) 11L), //passing 11
tp2); //passing "hello"
</c>
|
|}

====Wrapper functions in final mode====
Due to the potential optimization described above, in final mode two C wrapper functions are generated:
*one which expects the closed arguments as a tuple (encapsulated). The only difference to the frozen wrapper is how the '''agent callee''' is calculated.
*and one that expects them as separate parameters.

For the '''agent creation''':
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<eiffel>
agent c.f (?, 1, ?)
</eiffel>
|}
the following wrapper functions are generated:
{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<c>
EIF_REFERENCE _fAaatpmf_2_4 (
EIF_REFERENCE (*f_ptr)(EIF_REFERENCE,
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE),
EIF_TYPED_ELEMENT* closed,
EIF_TYPED_ELEMENT* open)
{
return f_ptr (closed [1].element.rarg,
open [1].element.i32arg,
closed [2].element.i32arg,
open [2].element.rarg);
}
</c>
|
<c>
EIF_REFERENCE __fAaatpmf_2_4 (
EIF_REFERENCE (*f_ptr)(EIF_REFERENCE,
EIF_INTEGER_32,
EIF_INTEGER_32,
EIF_REFERENCE),
EIF_TYPED_ELEMENT* closed,
EIF_INTEGER_32 op_2,
EIF_REFERENCE op_4)
{
return f_ptr (closed [1].element.rarg,
op_2,
closed [2].element.i32arg,
op_4);
}
</c>
|}
The name of the wrapper for the encapsulated closed arguments always starts with one '_', whereas the other one starts with two underlines.

====Melted agent creator====
Of course it is possible that the '''agent creation''' is melted and hence there is no wrapper. For this situation the Eiffel runtime provides two generic wrapper functions:

<code>[c, N]
RT_LNK void rout_obj_call_procedure_dynamic (
int stype_id, int feature_id, int is_precompiled, int is_basic_type, int is_inline_agent, EIF_TYPED_ELEMENT* closed_args,
int closed_count, EIF_TYPED_ELEMENT* open_args, int open_count, EIF_REFERENCE open_map);

RT_LNK void rout_obj_call_function_dynamic (
int stype_id, int feature_id, int is_precompiled, int is_basic_type, int is_inline_agent, EIF_TYPED_ELEMENT* closed_args,
int closed_count, EIF_TYPED_ELEMENT* open_args, int open_count, EIF_REFERENCE open_map, void* res);
</code>

These functions calculate the '''agent callee''' with the static type id and a feature id. Furthermore the reordering of open and closed arguments has to be done at agent call time with help of the open_map.

== Strategy for optimizing dotnet Agent Calls ==
Work in progress!
Compared to the Classic version, dotnet Agent Calls are slow. The a short look at feature apply of class FUNCTION shows why:

<e>
apply
-- Call function with `operands' as last set.
do
if attached rout_disp.invoke (target_object, internal_operands) as al_last_result then
last_result := al_last_result
end
end
</e>

The actual call is done through reflection. Additionally, in dotnet the two major optimizations are missing:

*Directly passing the elements of manifest tuples as parameters. (And hence not creating the tuple)
*Computing the reordering of closed and open operands at compile time. (By generating the proper wrapper)

All these three issues can be removed.

For every '''agent creation''' we create:
* A delegate type that requires two Tuples (closed and open arguments) as arguments.
* A static method that conforms to this delegate type. This method does the ordering of closed and open arguments and calls the '''agent callee'''.
* A second delegate type, that requires one Tuple (closed arguments) and all the open arguments as arguments.
* A second static method which conforms to the second delegate type and does the ordering and '''agent callee''' call.

Immutable Interface

2014-02-01T18:20:44Z

Conaclos: English corrections

[[Category:ECMA]]
[[Category:Immutability]]
{{Research}}
== Introduction ==
Eiffel Base 2 relies on partial (see below) immutable interfaces to design better abstractions and to allow a better use of the library.
This page sketch a solution to allow full immutable interface designs.

== Definition ==
An interface is immutable if it exports only queries. The routines exported to no classes are not included in the class interface.
Note that an immutable class has an immutable interface and more queries must be pure, i.e. with no side-effect.

== Issue ==
Immutable interfaces are not conceivable in the current state of the Eiffel Standard.
Indeed, all classes inherit of ANY. However ANY has not an immutable interface, it exports some commands. Therefore no immutable interface is conceivable.

ANY class interface (queries are omitted):
<e>
class interface
ANY

feature -- Duplication

copy (other: like Current)
-- Update current object using fields of object attached
-- to `other', so as to yield equal objects.
require
type_identity: same_type (other)
ensure
is_equal: Current ~ other

frozen deep_copy (other: like Current)
-- Effect equivalent to that of:
-- copy (`other' . deep_twin)
ensure
deep_equal: deep_equal (Current, other)

feature -- Basic Operations

default_rescue
-- Process exception for routines with no Rescue clause.
-- (Default: do nothing.)

frozen do_nothing
-- Execute a null action.

feature -- Output

print (o: detachable ANY)
-- Write terse external representation of `o'
-- on standard output.

end
</e>

== Make ANY as immutable interface ==
=== Export commands to no classes ===
* The command 'default_rescue' allows to change an internal behavior. This command can be exported to no classes.

* The command 'do_nothing' is a procedure specially interesting for agent uses.
A qualified call of 'do_nothing' on any objects is not useful. An interesting use can be:
<e>
class
EXAMPLE

feature

do_something
do
do_something_with (agent {A}.do_nothing)
end

do_something_with (a: PROCEDURE [ANY, TUPLE [A]])
do end

end
</e>

However the contravariance (concept not introduced yet) of the second generic parameter of PROCEDURE can remove this use:
<e>
class
EXAMPLE

feature

do_something
do
do_something_with (agent do_nothing)
end

do_something_with (a: PROCEDURE [ANY, TUPLE [A]])
do end
</e>

Therefore the command 'do_nothing' can be exported to no classes.

* The command 'print' could be called only with unqualified calls. It can be too exported to no classes.

* The commands 'copy' and 'deep_copy' are probably used mainly through the queries 'twin' and respectively 'deep_twin'.
Export this commands to no classes seems have no important disturbance. It is always possible to export its in descendants.

However, we can easily imagine that 'twin' and 'deep_twin' create a new object and then apply 'copy' and respectively 'deep_copy'.
This process does not follow the Eiffel creation philosophy.
Maybe it is an opportunity to correct it and then to write the queries 'twin' and 'deep_twin' with Eiffel code.

A solution would be to make both commands as creation commands.
<e>
class
ANY

create
copy,
deep_copy,
default_create

feature {NONE}-- Initialization

copy (other: like Current)
-- Update current object using fields of object attached
-- to `other', so as to yield equal objects.
require
type_identity: same_type (other)
external
"built_in"
ensure
is_equal: Current ~ other
end

-- ...

feature -- Duplication

frozen twin: like Current
-- New object equal to `Current'
-- `twin' calls `copy'; to change copying/twinning semantics, redefine `copy'.
do
create Result.copy (Current)
ensure
is_equal: Result ~ Current
end

-- ...

end
</e>
The both commands can be exported to no classes and two queries can be writed in Eiffel code.
However the developer must declare the creation commands for each effective class.

To remove this issue we can introduce the inherited creation command mechanism.

=== Inherited Creation Command ===
A simple addition to Eiffel could be to allow the create clause in deferred classes.
The creation commands declared in deferred classes would be inherited creation commands, i.e. creation commands implicitly declared in each descendants.

If an effective class declares no new creation commands then all inherited creation commands and the command 'default_create' are creation commands.
If an effective class declares new creation commands then all inherited creation commands and new ones are creation commands.
An inherited creation command can be declared again in an effective class. This possibility allows then all inherited commands as creation commands without 'default_create' (except if 'default_create' is an inherited creation command).

<e>
deferred class
A

create -- inherited
make

feature -- Initialization

make (a_n: INTEGER)
deferred end

end
</e>
<e>
class
B

inherit
A

feature
-- 'make' and 'default_create' are creation procedures

end
</e>
<e>
class
C

inherit
A

create
make

feature
-- 'make' is a creation procedure

end
</e>

This addition does not affect existing code. The compatibility is preserved.
And more it can be useful in constrained generic context.

=== ANY and inherited creation commands ===
The mechanism described in the previous section is not usable on ANY. Indeed, ANY is an effective class.
However is it very useful to allow the creation of ANY instance?

I have not examples of use of ANY instances. Maybe it is more relevant to make ANY as deferred class and then to use the inherited creation command mechanism.

<e>
deferred class
ANY

create -- inherited creation commands
copy,
deep_copy

feature
-- ...

end
</e>

== Conclusion ==
Export all ANY class's commands allows the design of full immutable interfaces.

In addition, the inherited creation command concept is a minimal mechanism compatible with existing software. It introduces no new keyword and allows to write two queries of ANY in Eiffel code.

EiffelStudio Wish List

2014-01-12T11:40:37Z

Conaclos: Postcondition for assigner commands

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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).

|
||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

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

|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2013-12-08T22:20:49Z

Conaclos: assigner command precision

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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).

|
||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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 request 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.
"[]", "<>", "{}"
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2013-12-08T22:14:21Z

Conaclos: TUPLE is now iterable

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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).

|
||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
* Assigner Commands are not droped when the procedure is renamed.
* Assigner Commands are not droped when the procedure is renamed or redefined.
* When a request 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.
"[]", "<>", "()", "{}"
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

Comparison of catcall solutions

2013-08-29T14:35:50Z

Conaclos: Export status restrictions not adressed for Default and explicit variance

[[Category:ECMA]]
[[Category:Catcall]]
== Motivation ==

By allowing covariant feature redefinition and hiding of features, the Eiffel language introduces the problem of catcalls (Changed Availability or Type). Currently the ECMA Eiffel standard does not specify how the occurrence of catcalls should be statically rejected.

The purpose of this document is to show a comparison between different proposals on how to handle the issue of preventing catcalls.

== Criteria for a solution ==

To be able to judge a solution we use the following criteria which we consider as important:

; Syntax overhead : How much syntax will be added to the language in order to express safe covariance and generics?
; Covariance on non-generic types : Are covariant argument redefinitions addressed in the solution? How does the programmer express it?
; Export status restrictions : Is restriction of export status addressed in the solution? How does the programmer express it?
; Use of generic types : How is conformance of generics? Are catcalls for generics addressed in the solution? How does the programmer express it? Can generics be used as now or are there restrictions?
:; Agents : Can agents be modeled with the solution while being type safe and expressive?
:; Comparator : Can comparator types be modeled with the solution while being type safe and expressive?
; Complexity of the compiler check : Is it just a matter of doing one check or several?
; Complexity of the runtime : Does the runtime need more information to do assignment attempts or object tests?
; Whole-system analysis : Is a whole-system analysis necessary?
; Dynamic class and type loading : Is it safe to dynamically load new classes at runtime and instantiate new types?
; Backward compatibility : Is the solution backward compatible to existing source code?
:; Applicable per cluster : Can the solution be applied on a per cluster basis?
; Support of compiler/IDE : Can the compiler/IDE help in updating existing source code? How?

== General remarks ==

=== Checking feature calls ===

As the ''Single-level Call rule'' (8.25.3, VUSC) describes, a feature call is only valid if it is valid for every type in the dynamic type set. A simple solution would be that every feature call has to be checked for all possible descendants of the static target type. If this check is performed on a system, it will catch all catcalls - but also report false positives.

Some of the proposed solutions try to address this problem by finding a better approximation to the dynamic type set so that the false positives can be ruled out.

In general this is problematic as it requires a whole-system analysis, thus preventing the dynamic loading of new classes at run-time. The reason for this is that it is not known at compile time which features will be covariantly redefined by dynamically loaded classes.

This is only the case with non-generic types. For generics, it is known at compile time that all features containing a formal in the parameter list can be treated as covariantly redefined and corresponding precautions can be implemented via the type system and conformance rules which allow to load even generic types at run-time.

By the way, Eiffel Software has started to [[Single level call rule implementation|implement the basis of the ''single-level call rule'']] in it's Eiffel compiler. It is work in progress which revealed some implementation problems.

=== Generic vs. non-generic covariance ===

We can distinguish two different kinds of covariant argument redefinition:

* When a generic type is derived, the formal generic parameters will be replaced by the actual generic parameters. Given the current conformance rules for generics, this can be seen as a covariant redefinition for all features which contain a formal generic as an argument. A simple example is the change from <e>LIST [ANY]</e> to <e>LIST [INTEGER]</e> where the feature <e>put</e> changes signature from <e>ANY</e> to <e>INTEGER</e>.
* In the non-generic case, covariance happens for certain anchored type declarations and in the case of explicitly changing an argument type to a descendant. This happens in general only on a small subset of the features.

The main difference is that in the generic case, all features which have a formal generic parameter automatically change the signature in different derivations whereas the non-generic case only specific features are covariantly redefined (if any at all). Also, in the generic case it is known for all possible descendants which features are redefined covariantly.

This observation helps to understand the various proposals and to see their strengths and weaknesses:
* A proposal which operates on the feature level can be good for non-generic classes as you generally have a small number of features covariantly redefined and you only have to specify these features. In the case of generics this can become cumbersome as all features with formal generic parameters are always considered as covariantly redefined and thus for generics they always have to be considered.
* A proposal which operates on the type level is better suited for generics as you don't have to specify every single feature which has a formal generic parameter as argument. But they run into problems in the non-generic case if you look at anchored types - for example <e>like Current</e>. Due to the fact that you have a covariant redeclaration in every descendant with such a feature, operating on the type level means that you have to handle every descendant specifically whereas if you operated on the feature level you could just handle this single feature.
* You see that there are two families of features: Features with formal arguments and ordinary features which are covariantly redefined. The fundamental difference between these two families is that they can change their signature independently. From <e>LIST [ANY]</e> to <e>LIST [INTEGER]</e> only the features based on the formal change their signature while they don't change from <e>LIST [ANY]</e> to <e>LINKED_LIST [ANY]</e> where the ordinary ones do. If you don't want to restrict the programmers expressiveness these feature families have to be addressed separately and a ''one fits all'' solution does not exist.

=== Contravariant generics ===

The modeling of certain problems involving generics requires contravariance. The two examples which will be used are comparator objects and agents:

* If you want to compare objects using a comparator, it either needs to be able to compare objects of the exact type, or an ancestor. Thus if you want to compare strings, either a comparator for <e>STRING</e> or one for <e>ANY</e> is suitable.
* If you want to pass an argument of type <e>STRING</e> to an agent, the agent either has to accept a <e>STRING</e> or <e>ANY</e> argument (or no argument at all).

These problems can only be modeled if there is a way to express contravariant conformance for generics. This means that all proposed solutions which don't offer this possibility can't be used to model agents or comparator correctly and safely.

=== Catcall benchmark ===

[[Catcall checkpoints]]

== Overview of general solutions ==

The following proposals handle the case of covariance on non-generic and generic types.

=== [[Novariance]] ===

In the novariance proposal, covariant redefinition for arguments is prohibited. If covariance is needed for modeling purposes it can be [http://dev.eiffel.com/Covariance_through_renaming simulated by renaming].

The conformance between generics with different formal parameters is removed.

=== [[Forget / keep]] ===

With the forget and keep mechanisms you specify per type on the feature level which features need not to be called - these features can safely be redefined covariantly - or which features have to be available - these features have to be typesafe for all possible values of a caller object.

Reference: [http://dev.eiffel.com/Forget_/_Keep_Mechanism Article on dev.eiffel.com]

=== Dynamic typeset algorithm ===

The dynamic typeset algorithm does not change any semantics of the types or the conformance as it is in Eiffel already, it only does an abstract execution of the system to limit the possibilities per feature call which have to be checked if they are safe.

=== [[Interval types]] ===

Interval types allow to define each type as an interval with a lower and upper type as boundary. This limits the dynamic type set and thus restricts the number of features which need to be checked for system-validity. In addition to this, it defines rules which handle the case of features with formal arguments.

=== [[Read-write types]] ===

Read-write types are a solution which can model interval types and usage-site variance. It splits a type into a ''read'' type and a ''write'' type. The read type defines the applicable features and the write type the signature to check for valid arguments.

=== [[Default and explicit variance]] ===
Default and explicit variance is inspired of usage-site variance and detachable proposition.
The proposition add no new keyword.

== Overview of solutions for non-generics ==

These proposal only address the case for non-generics. For generic catcalls another solution (e.g. wildcard generics) can be used.

=== [[Restrict types]] ===

With restrict types you specify per type on the type level which descendant types that are allowed. Only these types can be assigned to such a variable, and all feature calls on these variables have to be valid for all possible types in this list.

Reference: [http://se.inf.ethz.ch/cgi-bin/ecma/index.cgi?IssueFLEX_CATCALL IssueFLEX_CATCALL on ECMA wiki] 
Reference: Discussion in ECMA mailinglist named ''Catcall removal: another proposal'', [[Restrict types mail|available in parts]]

=== [[DOG proposal]] ===

With the DOG proposal, features which can be covariantly redefined have to be marked as such. These features can only be called on specially marked entities which have a restricted conformance, thus preventing assignments from descendants with potential covariantly redefined arguments.

Reference: [http://se.inf.ethz.ch/cgi-bin/ecma/index.cgi?IssueDOG IssueDOG on ECMA wiki]

== Overview of solutions for generics ==

These proposal only address the case for generics. For non-generic catcalls another solution (e.g. novariance) can be used.

=== [[Usage-site variance]] ===

This solution lets the programmer decide on the instantiation of a generic if the generic parameter should be covariant, contravariant or invariant. Depending on the variance, the applicable features of the type and the conformance rules to other generic types are changed.

Reference: [http://pag.csail.mit.edu/reading-group/variance-ECOOP02.pdf On variance-based subtyping for parametric types]

=== [[Definition-site variance]] ===

This solution lets the programmer decide in the definition of a generic class if the generic parameter should be covariant, contravariant or invariant. Depending on the variance, the formal generic can only appear at the argument, only appear as a result type or appear in both places. Also the conformance is adapted depending on the variance of the generic parameter.

This is the solution which is implemented in the CLR, although not supported by generics in C# which are novariant.

Reference: [http://blogs.msdn.com/rmbyers/archive/2006/06/01/613690.aspx Article about generics in CLR]

Note: There is also a [http://fams.de/text/type-safe-eiffel.html proposal by Bernd Schoeller] about ''variant and invariant'' generics which is a subset of this one and thus not explained in detail.

=== Wildcard generics ===

This mechanism extends the [[usage-site variance]] by adding a wildcard to the generic derivation. This wildcard denotes unspecified types and limits the use of features with generic parameters or result types over conformance to the wildcard types.

Since the mechanism is almost identical to the usage-site variance, it will not be looked at in more detail. Please refer to the reference article for more information.

Reference: [http://www.jot.fm/issues/issue_2004_12/article5 Adding Wildcards to the Java Programming Language]

== Overview of dynamic solutions ==

These proposals do not prevent catcalls at compile-time but introduce means to handle catcalls at runtime.

=== [[Detachable types]] ===

This solution allows covariantly redefined features only to use detachable types. Through this mechanism, an object test is necessary before an argument can be used. This forces the programmer to test arguments for validity.

Reference: [http://se.ethz.ch/~meyer/publications/lncs/attached.pdf Article about ''attached types'' by Bertrand Meyer] 
Reference: [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA Eiffel standard 2nd edition of June 2006]

=== Recast ===

In the recast proposal, the programmer has to specify a transformation function when covariantly redefining a feature which can transform the old argument types to the new ones.

Reference: [http://se.inf.ethz.ch/cgi-bin/ecma/index.cgi?IssueCAT IssueCAT on ECMA wiki] 
Reference: [http://www.inf.ethz.ch/~meyer/ongoing/covariance/recast.pdf Article about recast]

=== Exceptions ===

Another way of handling catcalls at runtime is to raise exceptions. It can be required or not to provide a rescue clause which handles the case of the catcall.

== Combinations ==

It is also possible to combine different proposals:

* Novariance for non-generic features and usage-site variance for generics .
* Forget / keep for non-generic features and definition-site variance for generics.
* DOG proposal for non-generic features and wildcard generics.
* ...

== Results ==

The following table summarizes the support of the various solutions to the criteria described above which can be used to judge a catcall solution.

This results can be differently interpreted, so the colors may not be totally accurate. See the [[Comparison of catcall solutions#Table_explained|explanation at the end of the table]] for more information

=== General solutions ===

{| border=1 cellpadding=2

|- style="visibility: hidden"
| style="width:20%" |
| style="width:20%" |
| style="width:20%" |
| style="width:20%" |
| style="width:20%" |

|-

! Criteria
! [[Novariance]]
! [[Forget / keep]]
! Dynamic typeset algorithm
! Default and explicit variance

|-

! Syntax overhead
| {{Green|No}}
| {{Red|Big}}: forget/keep clauses per type
| {{Green|No}}
| {{Green|No}}

|-

! Covariance on non-generic types
| {{Red|Not allowed}}
| {{Green|Allowed}}
| {{Green|Allowed}}
| {{Green|Allowed}}

|-

! Export status restrictions
| {{Red|Not allowed}}
| {{Green|Allowed}}
| {{Green|Allowed}}
| Not addressed

|-

! Use of generic types
| {{Red|Very limited}}: Only invariant conformance
| {{Orange|Limited}}: Conformance restricted (''keep all'' as default) {{Orange|Limited}}: Use restricted (''forget all'' as default)
| {{Green|As it is now}}
| {{Orange|Limited}}: Conformance is limited {{Green|Safe}}

|-

! Agents
| {{Orange|Limited}} {{Green|Safe}}
| {{Orange|Limited}} {{Green|Safe}}
| {{Red|As it is now}}
| {{Green|Fully supported}} {{Green|Safe}} - Class change needed for contravariant conformance

|-

! Comparator
| {{Red|Not supported}}
| {{Red|Not supported}}
| {{Red|Not supported}}
| {{Green|Supported}}

|-

! Complexity of compiler check
| {{Green|Small}}
| {{Orange|Medium}}: Check of feature call for all descendants; Conformance check on forget/keep clauses
| {{Red|Big}}: Iterative abstract system execution
| {{Green|Small}}: Check features for determinate the variance

|-

! Complexity of runtime
| {{Green|Small}}: As it is now
| {{Orange|Medium}}: Need to know cat features for object tests
| {{Green|Small}}: As it is now
| {{Green|Small}}: As it is now

|-

! Whole-system analysis
| {{Green|No}}
| {{Red|Yes}}: use of ''forget all'' depends on system
| {{Red|Yes}}
| {{Green|No}}

|-

! Dynamic class and type loading
| {{Green|Yes}}
| {{Red|No}}
| {{Red|No}}
| {{Green|Yes}}

|-

! Backward compatibility
| {{Red|Very limited}}
| {{Orange|Limited}}
| {{Green|Full}}
| {{Red|Very limited}}: All covariant redefinition of feature argument must be declared as variant. More restrcited conformance for generics.

|-

! Support of IDE (Source changes)
| {{Green|Not needed}}
| {{Orange|Possible}}: Can propose forget/keep clauses
| {{Green|Not needed}}
| {{Orange|Possible}}: Can propose variant mark for unsafe redefinition and for automatic generic variance detection.
|}

=== Solutions for non-generics ===

{| border=1 cellpadding=2

|- style="visibility: hidden"
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |

|-

! Criteria
! [[Restrict types]]
! [[DOG proposal]]

|-

! Syntax overhead
| {{Red|Big}}: Restrict clause per type declaration
| {{Orange|Medium}}: ''cat'' on features and on type declarations

|-

! Covariance on non-generic types
| {{Green|Allowed}}
| {{Green|Allowed}}

|-

! Export status restrictions
| {{Green|Allowed}}
| {{Green|Allowed}}

|-

! Use of generic types
| Not addressed
| Not addressed

|-

! Agents
| Not addressed
| Not addressed

|-

! Comparator
| Not addressed
| Not addressed

|-

! Complexity of compiler check
| {{Orange|Medium}}: Check of feature call for all descendants; Conformance check on restrict clauses
| {{Green|Small}}: Check of ''cat'' on conformance

|-

! Complexity of runtime
| not yet considered
| {{Green|Small}}

|-

! Whole-system analysis
| {{Orange|Partial}}
| {{Green|No}}

|-

! Dynamic class and type loading
| {{Orange|Limited}}
| {{Green|Yes}}

|-

! Backward compatibility
| {{Red|Very limited}}
| {{Red|Very limited}}

|-

! Support of IDE (Source changes)
| {{Orange|Possible}}: Can propose restrict clauses
| {{Orange|Possible}}: Can propose ''cat'' marks

|}

=== Solutions for generics ===

{| border=1 cellpadding=2

|- style="visibility: hidden"
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |

|-

! Criteria
! [[Usage-site variance]]
! [[Definition-site variance]]
! Wildcard generics

|-

! Syntax overhead
| {{Orange|Medium}}: Variance marks per generic type
| {{Green|Small}}: Variance marks per generic class definition
| {{Orange|Medium}}: Variance marks per generic type

|-

! Covariance on non-generic types
| Not addressed
| Not addressed
| Not addressed
|-

! Export status restrictions
| Not addressed
| Not addressed
| Not addressed

|-

! Use of generic types
| {{Orange|Limited}}: Conformance is limited {{Green|Safe}}
| {{Orange|Limited}}: Conformance is limited {{Green|Safe}}
| {{Orange|Limited}}: Conformance is limited {{Green|Safe}}

|-

! Agents
| {{Green|Fully supported}} {{Green|Safe}}
| {{Green|Fully supported}}: If tuples can be specified covariantly {{Green|Safe}}
| {{Green|Fully supported}} {{Green|Safe}}

|-

! Comparator
| {{Green|Supported}}
| {{Green|Supported}}
| {{Green|Supported}}

|-

! Complexity of compiler check
| {{Green|Small}}: Consider variance in conformance check
| {{Green|Small}}: Consider variance in conformance check
| {{Green|Small}}: Consider variance in conformance check

|-

! Complexity of runtime
| {{Green|Small}}: Consider variance in object test
| {{Green|Small}}: Consider variance in object test
| {{Green|Small}}: Consider variance in object test

|-

! Whole-system analysis
| {{Green|No}}
| {{Green|No}}
| {{Green|No}}

|-

! Dynamic class and type loading
| {{Green|Yes}}
| {{Green|Yes}}
| {{Green|Yes}}

|-

! Backward compatibility
| {{Orange|Limited}}: Use of generics changed due to conformance
| {{Red|Very limited}}: Libraries need redesign
| {{Orange|Limited}}: Use of generics changed due to conformance

|-

! Support of IDE (Source changes)
| {{Orange|Possible}}: Can propose variance marks
| {{Red|Not possible}}: Libraries need redesign
| {{Orange|Possible}}: Can propose variance marks/wildcards

|}

=== Dynamic solutions ===

{| border=1 cellpadding=2

|- style="visibility: hidden"
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |

|-

! Criteria
! [[Detachable types]]
! Recast
! Exceptions

|-

! Syntax overhead
| {{Green|Small}}: Detachment marks
| {{Red|Big}}: Recast clauses, recast features
| {{Orange|Medium}}: If rescue clause mandatory {{Green|No}}: If rescue clause not needed

|-

! Covariance on non-generic types
| {{Red|Very limited}}: Only detached arguments, no expanded arguments
| {{Green|Allowed}}
| {{Green|Allowed}}
|-

! Export status restrictions
| Not addressed
| Not addressed
| Not addressed

|-

! Use of generics
| {{Red|Very limited}}: Only detachable formal arguments
| {{Red|Very limited}}: Recast clause for all features with formal generics
| {{Green|As it is now}}

|-

! Agents
| {{Red|As it is now}}
| {{Red|As it is now}}
| {{Red|As it is now}}

|-

! Comparator
| {{Red|Not supported}}
| {{Red|Not supported}}
| {{Red|Not supported}}

|-

! Complexity of compiler check
| {{Green|Small}}: As it is now
| {{Green|Small}}: As it is now
| {{Green|Small}}: As it is now

|-

! Complexity of runtime
| {{Green|Small}}: As it is now
| {{Orange|Medium}}: Check for catcalls and do recast
| {{Orange|Medium}}: Check for catcalls and raise exception

|-

! Whole-system analysis
| {{Green|No}}
| {{Green|No}}
| {{Green|No}}

|-

! Dynamic class and type loading
| {{Green|Yes}}
| {{Green|Yes}}
| {{Green|Yes}}

|-

! Backward compatibility
| {{Red|Very limited}}: All covariant and generic features become detached
| {{Red|Very limited}}: All covariant and generic features need recast clause
| {{Orange|Limited}}: If rescue clause is mandatory {{Green|Full}}: If rescue clause not needed

|-

! Support of IDE (Source changes)
| {{Orange|Possible}}: Can propose detachment marks
| {{Red|Not possible}}: Programmer must provide recast clause
| {{Red|Not possible}}: If rescue clause mandatory {{Green|Not needed}}: If rescue clause not needed

|}

=== Table explained ===

; Syntax overhead : {{Green|Small}} if a keyword/mark is needed per class/feature declaration; {{Orange|Medium}} if a keyword/mark is neede per type declaration; {{Red|Big}} if a clause is needed per type declaration.
; Use of generics : {{Green|As it is now}} if assignments are possible if generic parameters conform; {{Orange|Limited}} is some restrictions in the use or the conformance between generics exist; {{Red|Very limited}} a lot of restrictions in the use or the conformance between generics exist.
; Agents : {{Green|Fully supported}} if all safe assignments are allowed; {{Orange|Limited}} if not all safe assignments are allowed; {{Red|As it is now}} if unsafe assignments are still possible.
; Comparator : {{Green|Supported}} if for a comparator all safe assignments are permitted (i.e. contravariant assignments); {{Red|Not supported}} if only exact type or even (unsafe) subtypes can be assigned.
; Support of IDE (Source changes) : {{Green|Not needed}} if everything still works the same; {{Orange|Possible}} if the compiler can suggest clauses or marks; {{Red|Not possible}} if the programmer has to specify additional features/instructions.

== Personal opinions ==

[[Personal view about catcall solution]]

Comparison of catcall solutions

2013-08-29T14:31:27Z

Conaclos: Correction for Default and explicit variance

[[Category:ECMA]]
[[Category:Catcall]]
== Motivation ==

By allowing covariant feature redefinition and hiding of features, the Eiffel language introduces the problem of catcalls (Changed Availability or Type). Currently the ECMA Eiffel standard does not specify how the occurrence of catcalls should be statically rejected.

The purpose of this document is to show a comparison between different proposals on how to handle the issue of preventing catcalls.

== Criteria for a solution ==

To be able to judge a solution we use the following criteria which we consider as important:

; Syntax overhead : How much syntax will be added to the language in order to express safe covariance and generics?
; Covariance on non-generic types : Are covariant argument redefinitions addressed in the solution? How does the programmer express it?
; Export status restrictions : Is restriction of export status addressed in the solution? How does the programmer express it?
; Use of generic types : How is conformance of generics? Are catcalls for generics addressed in the solution? How does the programmer express it? Can generics be used as now or are there restrictions?
:; Agents : Can agents be modeled with the solution while being type safe and expressive?
:; Comparator : Can comparator types be modeled with the solution while being type safe and expressive?
; Complexity of the compiler check : Is it just a matter of doing one check or several?
; Complexity of the runtime : Does the runtime need more information to do assignment attempts or object tests?
; Whole-system analysis : Is a whole-system analysis necessary?
; Dynamic class and type loading : Is it safe to dynamically load new classes at runtime and instantiate new types?
; Backward compatibility : Is the solution backward compatible to existing source code?
:; Applicable per cluster : Can the solution be applied on a per cluster basis?
; Support of compiler/IDE : Can the compiler/IDE help in updating existing source code? How?

== General remarks ==

=== Checking feature calls ===

As the ''Single-level Call rule'' (8.25.3, VUSC) describes, a feature call is only valid if it is valid for every type in the dynamic type set. A simple solution would be that every feature call has to be checked for all possible descendants of the static target type. If this check is performed on a system, it will catch all catcalls - but also report false positives.

Some of the proposed solutions try to address this problem by finding a better approximation to the dynamic type set so that the false positives can be ruled out.

In general this is problematic as it requires a whole-system analysis, thus preventing the dynamic loading of new classes at run-time. The reason for this is that it is not known at compile time which features will be covariantly redefined by dynamically loaded classes.

This is only the case with non-generic types. For generics, it is known at compile time that all features containing a formal in the parameter list can be treated as covariantly redefined and corresponding precautions can be implemented via the type system and conformance rules which allow to load even generic types at run-time.

By the way, Eiffel Software has started to [[Single level call rule implementation|implement the basis of the ''single-level call rule'']] in it's Eiffel compiler. It is work in progress which revealed some implementation problems.

=== Generic vs. non-generic covariance ===

We can distinguish two different kinds of covariant argument redefinition:

* When a generic type is derived, the formal generic parameters will be replaced by the actual generic parameters. Given the current conformance rules for generics, this can be seen as a covariant redefinition for all features which contain a formal generic as an argument. A simple example is the change from <e>LIST [ANY]</e> to <e>LIST [INTEGER]</e> where the feature <e>put</e> changes signature from <e>ANY</e> to <e>INTEGER</e>.
* In the non-generic case, covariance happens for certain anchored type declarations and in the case of explicitly changing an argument type to a descendant. This happens in general only on a small subset of the features.

The main difference is that in the generic case, all features which have a formal generic parameter automatically change the signature in different derivations whereas the non-generic case only specific features are covariantly redefined (if any at all). Also, in the generic case it is known for all possible descendants which features are redefined covariantly.

This observation helps to understand the various proposals and to see their strengths and weaknesses:
* A proposal which operates on the feature level can be good for non-generic classes as you generally have a small number of features covariantly redefined and you only have to specify these features. In the case of generics this can become cumbersome as all features with formal generic parameters are always considered as covariantly redefined and thus for generics they always have to be considered.
* A proposal which operates on the type level is better suited for generics as you don't have to specify every single feature which has a formal generic parameter as argument. But they run into problems in the non-generic case if you look at anchored types - for example <e>like Current</e>. Due to the fact that you have a covariant redeclaration in every descendant with such a feature, operating on the type level means that you have to handle every descendant specifically whereas if you operated on the feature level you could just handle this single feature.
* You see that there are two families of features: Features with formal arguments and ordinary features which are covariantly redefined. The fundamental difference between these two families is that they can change their signature independently. From <e>LIST [ANY]</e> to <e>LIST [INTEGER]</e> only the features based on the formal change their signature while they don't change from <e>LIST [ANY]</e> to <e>LINKED_LIST [ANY]</e> where the ordinary ones do. If you don't want to restrict the programmers expressiveness these feature families have to be addressed separately and a ''one fits all'' solution does not exist.

=== Contravariant generics ===

The modeling of certain problems involving generics requires contravariance. The two examples which will be used are comparator objects and agents:

* If you want to compare objects using a comparator, it either needs to be able to compare objects of the exact type, or an ancestor. Thus if you want to compare strings, either a comparator for <e>STRING</e> or one for <e>ANY</e> is suitable.
* If you want to pass an argument of type <e>STRING</e> to an agent, the agent either has to accept a <e>STRING</e> or <e>ANY</e> argument (or no argument at all).

These problems can only be modeled if there is a way to express contravariant conformance for generics. This means that all proposed solutions which don't offer this possibility can't be used to model agents or comparator correctly and safely.

=== Catcall benchmark ===

[[Catcall checkpoints]]

== Overview of general solutions ==

The following proposals handle the case of covariance on non-generic and generic types.

=== [[Novariance]] ===

In the novariance proposal, covariant redefinition for arguments is prohibited. If covariance is needed for modeling purposes it can be [http://dev.eiffel.com/Covariance_through_renaming simulated by renaming].

The conformance between generics with different formal parameters is removed.

=== [[Forget / keep]] ===

With the forget and keep mechanisms you specify per type on the feature level which features need not to be called - these features can safely be redefined covariantly - or which features have to be available - these features have to be typesafe for all possible values of a caller object.

Reference: [http://dev.eiffel.com/Forget_/_Keep_Mechanism Article on dev.eiffel.com]

=== Dynamic typeset algorithm ===

The dynamic typeset algorithm does not change any semantics of the types or the conformance as it is in Eiffel already, it only does an abstract execution of the system to limit the possibilities per feature call which have to be checked if they are safe.

=== [[Interval types]] ===

Interval types allow to define each type as an interval with a lower and upper type as boundary. This limits the dynamic type set and thus restricts the number of features which need to be checked for system-validity. In addition to this, it defines rules which handle the case of features with formal arguments.

=== [[Read-write types]] ===

Read-write types are a solution which can model interval types and usage-site variance. It splits a type into a ''read'' type and a ''write'' type. The read type defines the applicable features and the write type the signature to check for valid arguments.

=== [[Default and explicit variance]] ===
Default and explicit variance is inspired of usage-site variance and detachable proposition.
The proposition add no new keyword.

== Overview of solutions for non-generics ==

These proposal only address the case for non-generics. For generic catcalls another solution (e.g. wildcard generics) can be used.

=== [[Restrict types]] ===

With restrict types you specify per type on the type level which descendant types that are allowed. Only these types can be assigned to such a variable, and all feature calls on these variables have to be valid for all possible types in this list.

Reference: [http://se.inf.ethz.ch/cgi-bin/ecma/index.cgi?IssueFLEX_CATCALL IssueFLEX_CATCALL on ECMA wiki] 
Reference: Discussion in ECMA mailinglist named ''Catcall removal: another proposal'', [[Restrict types mail|available in parts]]

=== [[DOG proposal]] ===

With the DOG proposal, features which can be covariantly redefined have to be marked as such. These features can only be called on specially marked entities which have a restricted conformance, thus preventing assignments from descendants with potential covariantly redefined arguments.

Reference: [http://se.inf.ethz.ch/cgi-bin/ecma/index.cgi?IssueDOG IssueDOG on ECMA wiki]

== Overview of solutions for generics ==

These proposal only address the case for generics. For non-generic catcalls another solution (e.g. novariance) can be used.

=== [[Usage-site variance]] ===

This solution lets the programmer decide on the instantiation of a generic if the generic parameter should be covariant, contravariant or invariant. Depending on the variance, the applicable features of the type and the conformance rules to other generic types are changed.

Reference: [http://pag.csail.mit.edu/reading-group/variance-ECOOP02.pdf On variance-based subtyping for parametric types]

=== [[Definition-site variance]] ===

This solution lets the programmer decide in the definition of a generic class if the generic parameter should be covariant, contravariant or invariant. Depending on the variance, the formal generic can only appear at the argument, only appear as a result type or appear in both places. Also the conformance is adapted depending on the variance of the generic parameter.

This is the solution which is implemented in the CLR, although not supported by generics in C# which are novariant.

Reference: [http://blogs.msdn.com/rmbyers/archive/2006/06/01/613690.aspx Article about generics in CLR]

Note: There is also a [http://fams.de/text/type-safe-eiffel.html proposal by Bernd Schoeller] about ''variant and invariant'' generics which is a subset of this one and thus not explained in detail.

=== Wildcard generics ===

This mechanism extends the [[usage-site variance]] by adding a wildcard to the generic derivation. This wildcard denotes unspecified types and limits the use of features with generic parameters or result types over conformance to the wildcard types.

Since the mechanism is almost identical to the usage-site variance, it will not be looked at in more detail. Please refer to the reference article for more information.

Reference: [http://www.jot.fm/issues/issue_2004_12/article5 Adding Wildcards to the Java Programming Language]

== Overview of dynamic solutions ==

These proposals do not prevent catcalls at compile-time but introduce means to handle catcalls at runtime.

=== [[Detachable types]] ===

This solution allows covariantly redefined features only to use detachable types. Through this mechanism, an object test is necessary before an argument can be used. This forces the programmer to test arguments for validity.

Reference: [http://se.ethz.ch/~meyer/publications/lncs/attached.pdf Article about ''attached types'' by Bertrand Meyer] 
Reference: [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA Eiffel standard 2nd edition of June 2006]

=== Recast ===

In the recast proposal, the programmer has to specify a transformation function when covariantly redefining a feature which can transform the old argument types to the new ones.

Reference: [http://se.inf.ethz.ch/cgi-bin/ecma/index.cgi?IssueCAT IssueCAT on ECMA wiki] 
Reference: [http://www.inf.ethz.ch/~meyer/ongoing/covariance/recast.pdf Article about recast]

=== Exceptions ===

Another way of handling catcalls at runtime is to raise exceptions. It can be required or not to provide a rescue clause which handles the case of the catcall.

== Combinations ==

It is also possible to combine different proposals:

* Novariance for non-generic features and usage-site variance for generics .
* Forget / keep for non-generic features and definition-site variance for generics.
* DOG proposal for non-generic features and wildcard generics.
* ...

== Results ==

The following table summarizes the support of the various solutions to the criteria described above which can be used to judge a catcall solution.

This results can be differently interpreted, so the colors may not be totally accurate. See the [[Comparison of catcall solutions#Table_explained|explanation at the end of the table]] for more information

=== General solutions ===

{| border=1 cellpadding=2

|- style="visibility: hidden"
| style="width:20%" |
| style="width:20%" |
| style="width:20%" |
| style="width:20%" |
| style="width:20%" |

|-

! Criteria
! [[Novariance]]
! [[Forget / keep]]
! Dynamic typeset algorithm
! Default and explicit variance

|-

! Syntax overhead
| {{Green|No}}
| {{Red|Big}}: forget/keep clauses per type
| {{Green|No}}
| {{Green|No}}

|-

! Covariance on non-generic types
| {{Red|Not allowed}}
| {{Green|Allowed}}
| {{Green|Allowed}}
| {{Green|Allowed}}

|-

! Export status restrictions
| {{Red|Not allowed}}
| {{Green|Allowed}}
| {{Green|Allowed}}
| {{Red|Not allowed}}

|-

! Use of generic types
| {{Red|Very limited}}: Only invariant conformance
| {{Orange|Limited}}: Conformance restricted (''keep all'' as default) {{Orange|Limited}}: Use restricted (''forget all'' as default)
| {{Green|As it is now}}
| {{Orange|Limited}}: Conformance is limited {{Green|Safe}}

|-

! Agents
| {{Orange|Limited}} {{Green|Safe}}
| {{Orange|Limited}} {{Green|Safe}}
| {{Red|As it is now}}
| {{Green|Fully supported}} {{Green|Safe}} - Class change needed for contravariant conformance

|-

! Comparator
| {{Red|Not supported}}
| {{Red|Not supported}}
| {{Red|Not supported}}
| {{Green|Supported}}

|-

! Complexity of compiler check
| {{Green|Small}}
| {{Orange|Medium}}: Check of feature call for all descendants; Conformance check on forget/keep clauses
| {{Red|Big}}: Iterative abstract system execution
| {{Green|Small}}: Check features for determinate the variance

|-

! Complexity of runtime
| {{Green|Small}}: As it is now
| {{Orange|Medium}}: Need to know cat features for object tests
| {{Green|Small}}: As it is now
| {{Green|Small}}: As it is now

|-

! Whole-system analysis
| {{Green|No}}
| {{Red|Yes}}: use of ''forget all'' depends on system
| {{Red|Yes}}
| {{Green|No}}

|-

! Dynamic class and type loading
| {{Green|Yes}}
| {{Red|No}}
| {{Red|No}}
| {{Green|Yes}}

|-

! Backward compatibility
| {{Red|Very limited}}
| {{Orange|Limited}}
| {{Green|Full}}
| {{Red|Very limited}}: All covariant redefinition of feature argument must be declared as variant. More restrcited conformance for generics.

|-

! Support of IDE (Source changes)
| {{Green|Not needed}}
| {{Orange|Possible}}: Can propose forget/keep clauses
| {{Green|Not needed}}
| {{Orange|Possible}}: Can propose variant mark for unsafe redefinition and for automatic generic variance detection.
|}

=== Solutions for non-generics ===

{| border=1 cellpadding=2

|- style="visibility: hidden"
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |

|-

! Criteria
! [[Restrict types]]
! [[DOG proposal]]

|-

! Syntax overhead
| {{Red|Big}}: Restrict clause per type declaration
| {{Orange|Medium}}: ''cat'' on features and on type declarations

|-

! Covariance on non-generic types
| {{Green|Allowed}}
| {{Green|Allowed}}

|-

! Export status restrictions
| {{Green|Allowed}}
| {{Green|Allowed}}

|-

! Use of generic types
| Not addressed
| Not addressed

|-

! Agents
| Not addressed
| Not addressed

|-

! Comparator
| Not addressed
| Not addressed

|-

! Complexity of compiler check
| {{Orange|Medium}}: Check of feature call for all descendants; Conformance check on restrict clauses
| {{Green|Small}}: Check of ''cat'' on conformance

|-

! Complexity of runtime
| not yet considered
| {{Green|Small}}

|-

! Whole-system analysis
| {{Orange|Partial}}
| {{Green|No}}

|-

! Dynamic class and type loading
| {{Orange|Limited}}
| {{Green|Yes}}

|-

! Backward compatibility
| {{Red|Very limited}}
| {{Red|Very limited}}

|-

! Support of IDE (Source changes)
| {{Orange|Possible}}: Can propose restrict clauses
| {{Orange|Possible}}: Can propose ''cat'' marks

|}

=== Solutions for generics ===

{| border=1 cellpadding=2

|- style="visibility: hidden"
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |

|-

! Criteria
! [[Usage-site variance]]
! [[Definition-site variance]]
! Wildcard generics

|-

! Syntax overhead
| {{Orange|Medium}}: Variance marks per generic type
| {{Green|Small}}: Variance marks per generic class definition
| {{Orange|Medium}}: Variance marks per generic type

|-

! Covariance on non-generic types
| Not addressed
| Not addressed
| Not addressed
|-

! Export status restrictions
| Not addressed
| Not addressed
| Not addressed

|-

! Use of generic types
| {{Orange|Limited}}: Conformance is limited {{Green|Safe}}
| {{Orange|Limited}}: Conformance is limited {{Green|Safe}}
| {{Orange|Limited}}: Conformance is limited {{Green|Safe}}

|-

! Agents
| {{Green|Fully supported}} {{Green|Safe}}
| {{Green|Fully supported}}: If tuples can be specified covariantly {{Green|Safe}}
| {{Green|Fully supported}} {{Green|Safe}}

|-

! Comparator
| {{Green|Supported}}
| {{Green|Supported}}
| {{Green|Supported}}

|-

! Complexity of compiler check
| {{Green|Small}}: Consider variance in conformance check
| {{Green|Small}}: Consider variance in conformance check
| {{Green|Small}}: Consider variance in conformance check

|-

! Complexity of runtime
| {{Green|Small}}: Consider variance in object test
| {{Green|Small}}: Consider variance in object test
| {{Green|Small}}: Consider variance in object test

|-

! Whole-system analysis
| {{Green|No}}
| {{Green|No}}
| {{Green|No}}

|-

! Dynamic class and type loading
| {{Green|Yes}}
| {{Green|Yes}}
| {{Green|Yes}}

|-

! Backward compatibility
| {{Orange|Limited}}: Use of generics changed due to conformance
| {{Red|Very limited}}: Libraries need redesign
| {{Orange|Limited}}: Use of generics changed due to conformance

|-

! Support of IDE (Source changes)
| {{Orange|Possible}}: Can propose variance marks
| {{Red|Not possible}}: Libraries need redesign
| {{Orange|Possible}}: Can propose variance marks/wildcards

|}

=== Dynamic solutions ===

{| border=1 cellpadding=2

|- style="visibility: hidden"
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |

|-

! Criteria
! [[Detachable types]]
! Recast
! Exceptions

|-

! Syntax overhead
| {{Green|Small}}: Detachment marks
| {{Red|Big}}: Recast clauses, recast features
| {{Orange|Medium}}: If rescue clause mandatory {{Green|No}}: If rescue clause not needed

|-

! Covariance on non-generic types
| {{Red|Very limited}}: Only detached arguments, no expanded arguments
| {{Green|Allowed}}
| {{Green|Allowed}}
|-

! Export status restrictions
| Not addressed
| Not addressed
| Not addressed

|-

! Use of generics
| {{Red|Very limited}}: Only detachable formal arguments
| {{Red|Very limited}}: Recast clause for all features with formal generics
| {{Green|As it is now}}

|-

! Agents
| {{Red|As it is now}}
| {{Red|As it is now}}
| {{Red|As it is now}}

|-

! Comparator
| {{Red|Not supported}}
| {{Red|Not supported}}
| {{Red|Not supported}}

|-

! Complexity of compiler check
| {{Green|Small}}: As it is now
| {{Green|Small}}: As it is now
| {{Green|Small}}: As it is now

|-

! Complexity of runtime
| {{Green|Small}}: As it is now
| {{Orange|Medium}}: Check for catcalls and do recast
| {{Orange|Medium}}: Check for catcalls and raise exception

|-

! Whole-system analysis
| {{Green|No}}
| {{Green|No}}
| {{Green|No}}

|-

! Dynamic class and type loading
| {{Green|Yes}}
| {{Green|Yes}}
| {{Green|Yes}}

|-

! Backward compatibility
| {{Red|Very limited}}: All covariant and generic features become detached
| {{Red|Very limited}}: All covariant and generic features need recast clause
| {{Orange|Limited}}: If rescue clause is mandatory {{Green|Full}}: If rescue clause not needed

|-

! Support of IDE (Source changes)
| {{Orange|Possible}}: Can propose detachment marks
| {{Red|Not possible}}: Programmer must provide recast clause
| {{Red|Not possible}}: If rescue clause mandatory {{Green|Not needed}}: If rescue clause not needed

|}

=== Table explained ===

; Syntax overhead : {{Green|Small}} if a keyword/mark is needed per class/feature declaration; {{Orange|Medium}} if a keyword/mark is neede per type declaration; {{Red|Big}} if a clause is needed per type declaration.
; Use of generics : {{Green|As it is now}} if assignments are possible if generic parameters conform; {{Orange|Limited}} is some restrictions in the use or the conformance between generics exist; {{Red|Very limited}} a lot of restrictions in the use or the conformance between generics exist.
; Agents : {{Green|Fully supported}} if all safe assignments are allowed; {{Orange|Limited}} if not all safe assignments are allowed; {{Red|As it is now}} if unsafe assignments are still possible.
; Comparator : {{Green|Supported}} if for a comparator all safe assignments are permitted (i.e. contravariant assignments); {{Red|Not supported}} if only exact type or even (unsafe) subtypes can be assigned.
; Support of IDE (Source changes) : {{Green|Not needed}} if everything still works the same; {{Orange|Possible}} if the compiler can suggest clauses or marks; {{Red|Not possible}} if the programmer has to specify additional features/instructions.

== Personal opinions ==

[[Personal view about catcall solution]]

Default and explicit variance

2013-08-29T14:06:31Z

Conaclos: Minor improvements

[[Category:ECMA]]
[[Category:Catcall]]
{{Research}}
== Introduction ==
In first the limited variant typing is exposed. It checks all catcall checkpoints.
In the second part the mechanism is extended. It is less simple and explicit, but it enables a best transition.

== Limited variant typing ==
What is the advantages of covariance compared to a novariant typing?
* explicit and adaptative interface
* One routine

=== Variant typing ===
* A variant entity has '''the most restrictive type'''.
* A variant entity requires a simple object test to use the entity with the '''expected type'''.

Examples are available in next sections.

=== Feature redefinition ===
* Covariant redefinition of request result is allowed (as currently).
* Covariant redefinition of feature argument requires a variant typing on redefined feature or first feature definition.
'''The most restrictive type''' for a variant type argument is the type of the first feature definition.

The first rule is a stronger postcondition. The current semantic is not changed.

'''example 1:''' covariant redefinition of feature argument with 'variant' typing on redefined feature

Note:
* The object test is not needed.
* the type is not repeated in the object test.
* In the class interface the 'variant' is removed. Indeed, it is not possible to call 'eat' on an entity of type COW with a parameter of type FOOD.

<e>
class
ANIMAL

feature -- Access
last: FOOD

feature -- Eating
eat (f: like last)
require
True
do
last := f
ensure
True
end
end
</e>
<e>
class
COW

inherit
ANIMAL
redefine all end

feature -- Access
last: GRASS

feature -- Eating
eat (f: variant like last) -- or eat (f: variant GRASS)
require else
True
-- 'f' type = expected type. Here: GRASS
do
-- 'f' type = type of the first definition. Here: FOOD
if attached f as expected then
-- 'expected' type = expected type. Here: GRASS
last := expected
end
ensure then
True
-- 'f' type = type of the first definition. Here: FOOD
end

end
</e>

'''example 2:''' covariant redefinition of feature argument with 'variant' typing on first feature definition.
<e>
class
ANIMAL

feature -- Access
last: FOOD

feature -- Eating
eat (f: variant like last)
do
if attached f as expected then
last := expected
end
end
end
</e>

<e>
class
COW

inherit
ANIMAL
redefine last end

feature -- Access
last: GRASS

end
</e>

=== Generic conformance ===
Default: a generic is novariant

If a genric must be variant (covariant or contravariant or both) then the formal generic must be prefixed with the 'variant' mark.

The compiler must ensure that the variant generic checks one next rule:
* Generic used only on feature argument is contravariant.
* Generic used only on request result or feature argument with variant typing is covariant.
* Generic not used is both contravariant and covariant.

'''The most restrictive type''' for a variant generic argument is the constrained inheritance type.
'''
example:'''
<e>
deferred class
EXAMPLE [variant K, variant G]
-- K is contravariant and G is covariant

feature -- Access
first: G

item (i: K): G
deferred
end

end
</e>

Therefore the next code is valid:
<e>
local
a: EXAMPLE [INTEGER, COMPARABLE]; b: EXAMPLE [NUMERIC, STRING]
do
-- ...
a := b
end
</e>

==== Agent conformance ====
As explained for [[Usage-site variance]] the generic 'OPEN_ARGS' from ROUTINE, PROCEDURE, FUNCTION, PREDICATE must be contravariant.

<e>
class
ROUTINE [BASE_TYPE, variant OPEN_ARGS -> detachable TUPLE create default_create end]
-- ...
end
</e>

The generic 'OPEN_ARGS' is used on feature arguments, but also on request result.

The class should probably be redesigned. Indeed if contravariant is allowed then there may be a new contravariant catcall on request result.

In these classes there are only two requests using the generic as type:
<e>
operands: detachable OPEN_ARGS

empty_operands: OPEN_ARGS
do create Result ensure ... end
</e>

The second request is not used internally and may be problematic for creation: How create a tuple of not self-initialized and attached types?
The first is used in these features : 'target', 'is_equal', 'set_operands', 'copy', 'apply'

'is_equal', 'set_operands' and 'copy' rely on data model.
'apply' and 'target' are more sensitive. Indeed the problem is when there is an opened target.

'apply' could be restricted for no opened arguments.
<e>
apply
require
no_operands: open_count = 0
do
call (Void)
end
</e>
'target' could be modfied:
<e>
target: ANY
require
is_target_closed
do
-- ...
end
</e>

Or maybe it is better to separate opened target and closed target in two abstractions.

The redesign of agent classes is an opportunity to solve agent problems (see [[Minor-ECMA-problems]], [[Agents in SCOOP]]).

Another solution will be mentioned later.

Note:
The generic 'RESULT_TYPE' of FUNCTION class is used only on request result. Then it is a covariant generic. It is an expected point.

=== Comparison with other solutions ===
==== [[Detachable types]] (non-generic) ====
The variant typing is not in conflict with the void-safe typing.

And more the object test is not needed.

==== [[Usage-site variance]] (generic) ====
The variant typing is a supplier specification while usage-site variance is a client specification.

Another difference is the interface restriction of the usage-site variance. With the variant typing for generics the interface is fully aivailable.

=== Sub-conclusion ===
The limited variant typing is reasonable and expressive. It limits Eiffel changes and solves all catcall problems.

The proposal reuses an existing keyword.

The addition in TYPE class for reflexivity and dynamic object test is little.
Indeed two simple booleans "is_contravariant" and "is_covariant" for each generic is required.
<e>
generic_parameter_contravariant (i: INTEGER): BOOLEAN
-- Is `i'-th generic parameter contravariant?

generic_parameter_covariant (i: INTEGER): BOOLEAN
-- Is `i'-th generic parameter covariant?
</e>

A possible critical could be the generic conformance restriction. Propositions are mentioned below.

== Extended variant typing ==
=== Generic conformance ===
The variant mark is optional. The compiler infers the generic variance. It is a good point for backward compatibility.

* Generic used only on feature argument or request result with variant typing is contravariant.

==== Agent conformance ====
It is possible to declare 'operands' and 'empty_operands' as variant.
<e>
operands: variant detachable OPEN_ARGS

empty_operands: variant OPEN_ARGS
do create Result ensure ... end
</e>

'apply' and 'target' should be wrote again. For example:
<e>
apply
do
-- 'operands' type = constrained inheritance. Here: detachable TUPLE
if attached operands as args then
-- 'operands' type = request result type. Here: OPEN_ARGS
call (args)
else
call (Void)
end
end
</e>

=== Sub-conclusion ===
This part extend the proposition to enable a best backward compatibility and then a best transition.

== General discussions ==
=== Greater flexibility for generics ===
A lot of generics could be novariant, encouraging to propose a solution to have a new flexibility, but safe.
==== Wildcard generics ====
The request result type is the constrained inheritance type. And the type of the feature argument is (attached) NONE.
The new semantic of 'Void' is considered: Void is not a NONE instance.

<e>
local
a: ARRAY [?]; b: ARRAY [STRING]
o: ANY
do
-- ...
a := b
o := a.item (1)
a.put ("try") -- invalid call. The type expected is NONE.
end
</e>

However the wildcard generics will be used on request result or feature argument. A more power and elegent solution could be the parametrized routines.

==== Parametrized routines ====
<e>
do_something [G] (a: ARRAY [G]): G
require
a.count >= 1
do
Result := a.item (1)
end
</e>

==== Right abstraction ====
The wildcard generics and the parametrized routines introduce new constructs for Eiffel. Is there another solution avoiding this?

With a right abstraction it is possible to have flexible classes. It is comparable to the imuutable cocncept.

'''example:''' V_CONTAINER class of Eiffel Base 2
To obtain the genric covariance behavior it is necessary to have:
* V_ITERATOR must have a covariant generic.
* TUPLE should be a read-only interface (V_MUTABLE_TUPLE would be the current TUPLE class). Therefore TUPLE could be conformed to V_SEQUENCE and V_MUTABLE_TUPLE conformed to V_ARRAY. Note that only the readonly interface could be in the Eiffel Standard.

In V_CONTAINER class only two features should use the variant typing:
<e>
new_cursor: V_ITERATOR [G]
do ... end

occurrences (v: variant G): INTEGER
do
-- G -> ANY then 'v' type = ANY
across Current as it loop
if it.item = v then
Result := Result + 1
end
end
end

has (v: variant G)
local
it: like new_cursor
do
-- G -> ANY then 'v' type = ANY
it := new_cursor -- 'it' type = V_ITERATOR [ANY]
it.search_forth (v)
Result := not it.after
ensure
occurrences (v) = 1
end
</e>

In V_ITERATOR only two features should use the variant typing without object test!

With these changes the next code is valid:
<e>
local
a: V_CONTAINER [ANY]; b: V_CONTAINER [STRING]
do
a := b

end
</e>

==== Sub-conclusion ====
With a right abstraction and a smart use of variant typing for generics, it is possible to obtain a greater flexibility keeping a fully aivailable interface.

=== Limit changes ===
To limit code change and to increase typing consistency, we can change the semantic of 'variant'.

Contravariant redefinition of request result is not very useful.
The variant typing could be limited for covariant redefinition. There could have no effect on request result.

For generic conformance, a formal generic prefixed with the variant mark is covariant. The variant mark is not required on feature argument limiting code change.

However we have a problem: How mark a contravariant generic? There is three options:
* Another mark.
* 'frozen' mark for novariant generic and then no mark for contravariant generic: too restrictive since novariance concerns a lot of generic classes
* No prefixed mark means novariant or contravariant generic

=== Export status restrictions ===
Since the ECMA Eiffel Standard forbids the export restriction with conforming inheritance, it is not a problem.
However, the semantic can be changed to enable this restriction on conforming inheritance.

Restrict exportation should not cause a catcall. The mechanism could be used just to change the class interface.
<e>
deferred class
ANIMAL
feature
is_vegetarian: BOOLEAN
deferred end
end
</e>
<e>
class
COW
inherit
ANIMAL
export {NONE}
is_vegetarian
end
feature {NONE}
is_vegetarian: BOOLEAN = True
end
</e>
<e>
local
an_animal: ANIMAL; a_cow: COW
b: BOOLEAN
do
create a_cow
b := a_cow.is_vegetarian -- invalid call

an_animal := a_cow
b := an_animal .is_vegetarian -- valid call
end
</e>

The class interface is more simple and readable.

== Conclusion ==
The proposition uses no new keyword and solves the catcall problem.
It passes all [[Catcall checkpoints]].

The new generic conformance gives a natural safe and flexible static typing.
The variant typing enables to create adaptive interfaces keeping a safe static typing.

With a fine abstraction and the use of variant typing for generics, the genric conformance flexibility is little restricted. The contravariant for request result can then be discarded for simplicity.

There is no interface restriction ([[Interval types]] or [[Usage-site variance]]). Class interfaces are fully available.

== Your view ==
name:
comment:

...

Default and explicit variance

2013-08-29T13:47:54Z

Conaclos: Minor improvements

[[Category:ECMA]]
[[Category:Catcall]]
{{Research}}
== Introduction ==
In first the limited variant typing is exposed. It checks all catcall checkpoints.
In the second part the mechanism is extended. It is less simple and explicit, but it enables a best transition.

== Limited variant typing ==
What is the advantages of covariance compared to a novariant typing?
* explicit and adaptative interface
* One routine

=== Variant typing ===
* A variant entity has '''the most restrictive type'''.
* A variant entity requires a simple object test to use the entity with the '''expected type'''.

Examples are available in next sections.

=== Feature redefinition ===
* Covariant redefinition of request result is allowed (as currently).
* Covariant redefinition of feature argument requires a variant typing on redefined feature or first feature definition.
'''The most restrictive type''' for a variant type argument is the type of the first feature definition.

The first rule is a stronger postcondition. The current semantic is not changed.

'''example 1:''' covariant redefinition of feature argument with 'variant' typing on redefined feature

Note:
* The object test is not needed.
* the type is not repeated in the object test.
* In the class interface the 'variant' is removed. Indeed, it is not possible to call 'eat' on an entity of type COW with a parameter of type FOOD.

<e>
class
ANIMAL

feature -- Access
last: FOOD

feature -- Eating
eat (f: like last)
require
True
do
last := f
ensure
True
end
end
</e>
<e>
class
COW

inherit
ANIMAL
redefine all end

feature -- Access
last: GRASS

feature -- Eating
eat (f: variant like last) -- or eat (f: variant GRASS)
require else
True
-- 'f' type = expected type. Here: GRASS
do
-- 'f' type = type of the first definition. Here: FOOD
if attached f as expected then
-- 'expected' type = expected type. Here: GRASS
last := expected
end
ensure then
True
-- 'f' type = type of the first definition. Here: FOOD
end

end
</e>

'''example 2:''' covariant redefinition of feature argument with 'variant' typing on first feature definition.
<e>
class
ANIMAL

feature -- Access
last: FOOD

feature -- Eating
eat (f: variant like last)
do
if attached f as expected then
last := expected
end
end
end
</e>

<e>
class
COW

inherit
ANIMAL
redefine last end

feature -- Access
last: GRASS

end
</e>

=== Generic conformance ===
Default: a generic is novariant

If a genric must be variant (covariant or contravariant or both) then the formal generic must be prefixed with the 'variant' mark.

The compiler must ensure that the variant generic checks one next rule:
* Generic used only on feature argument is contravariant.
* Generic used only on request result or feature argument with variant typing is covariant.
* Generic not used is both contravariant and covariant.

'''The most restrictive type''' for a variant generic argument is the constrained inheritance type.
'''
example:'''
<e>
deferred class
EXAMPLE [variant K, variant G]
-- K is contravariant and G is covariant

feature -- Access
first: G

item (i: K): G
deferred
end

end
</e>

Therefore the next code is valid:
<e>
local
a: EXAMPLE [INTEGER, COMPARABLE]; b: EXAMPLE [NUMERIC, STRING]
do
-- ...
a := b
end
</e>

==== Agent conformance ====
As explained for [[Usage-site variance]] the generic 'OPEN_ARGS' from ROUTINE, PROCEDURE, FUNCTION, PREDICATE must be contravariant.

<e>
class
ROUTINE [BASE_TYPE, variant OPEN_ARGS -> detachable TUPLE create default_create end]
-- ...
end
</e>

The generic 'OPEN_ARGS' is used on feature arguments, but also on request result.

The class should probably be redesigned. Indeed if contravariant is allowed then there may be a new contravariant catcall on request result.

In these classes there are only two requests using the generic as type:
<e>
operands: detachable OPEN_ARGS

empty_operands: OPEN_ARGS
do create Result ensure ... end
</e>

The second request is not used internally and may be problematic for creation: How create a tuple of not self-initialized and attached types?
The first is used in these features : 'target', 'is_equal', 'set_operands', 'copy', 'apply'

'is_equal', 'set_operands' and 'copy' rely on data model.
'apply' and 'target' are more sensitive. Indeed the problem is when there is an opened target.

'apply' could be restricted for no opened arguments.
<e>
apply
require
no_operands: open_count = 0
do
call (Void)
end
</e>
'target' could be modfied:
<e>
target: ANY
require
is_target_closed
do
-- ...
end
</e>

Or maybe it is better to separate opened target and closed target in two abstractions.

The redesign of agent classes is an opportunity to solve agent problems (see [[Minor-ECMA-problems]], [[Agents in SCOOP]]).

Another solution will be mentioned later.

Note:
The generic 'RESULT_TYPE' of FUNCTION class is used only on request result. Then it is a covariant generic. It is an expected point.

=== Comparison with other solutions ===
==== [[Detachable types]] (non-generic) ====
The variant typing is not in conflict with the void-safe typing.

And more the object test is not needed.

==== [[Usage-site variance]] (generic) ====
The variant typing is a supplier specification while usage-site variance is a client specification.

Another difference is the interface restriction of the usage-site variance. With the variant typing for generics the interface is fully aivailable.

=== Sub-conclusion ===
The limited variant typing is reasonable and expressive. It limits Eiffel changes and solves all catcall problems.

The proposal reuses an existing keyword.

The addition in TYPE class for reflexivity and dynamic object test is little.
Indeed two simple booleans "is_contravariant" and "is_covariant" for each generic is required.
<e>
generic_parameter_contravariant (i: INTEGER): BOOLEAN
-- Is `i'-th generic parameter contravariant?

generic_parameter_covariant (i: INTEGER): BOOLEAN
-- Is `i'-th generic parameter covariant?
</e>

A possible critical could be the generic conformance restriction. Propositions are mentioned below.

== Extended variant typing ==
=== Generic conformance ===
The variant mark is optional. The compiler infers the generic variance. It is a good point for backward compatibility.

* Generic used only on feature argument or request result with variant typing is contravariant.

==== Agent conformance ====
It is possible to declare 'operands' and 'empty_operands' as variant.
<e>
operands: variant detachable OPEN_ARGS

empty_operands: variant OPEN_ARGS
do create Result ensure ... end
</e>

'apply' and 'target' should be wrote again. For example:
<e>
apply
do
-- 'operands' type = constrained inheritance. Here: detachable TUPLE
if attached operands as args then
-- 'operands' type = request result type. Here: OPEN_ARGS
call (args)
else
call (Void)
end
end
</e>

=== Sub-conclusion ===
This part extend the proposition to enable a best backward compatibility and then a best transition.

== General discussions ==
=== Greater flexibility for generics ===
A lot of generics could be novariant, encouraging to propose a solution to have a new flexibility, but safe.
==== Wildcard generics ====
The request result type is the constrained inheritance type. And the type of the feature argument is (attached) NONE.
The new semantic of 'Void' is considered: Void is not a NONE instance.

<e>
local
a: ARRAY [?]; b: ARRAY [STRING]
o: ANY
do
-- ...
a := b
o := a.item (1)
a.put ("try") -- invalid call. The type expected is NONE.
end
</e>

However the wildcard generics will be used on request result or feature argument. A more power and elegent solution could be the parametrized routines.

==== Parametrized routines ====
<e>
do_something [G] (a: ARRAY [G]): G
require
a.count >= 1
do
Result := a.item (1)
end
</e>

==== Right abstraction ====
The wildcard generics and the parametrized routines introduce new constructs for Eiffel. Is there another solution avoiding this?

With a right abstraction it is possible to have flexible classes. It is comparable to the imuutable cocncept.

'''example:''' V_CONTAINER class of Eiffel Base 2
To obtain the genric covariance behavior it is necessary to have:
* V_ITERATOR must have a covariant generic.
* TUPLE should be a read-only interface (V_MUTABLE_TUPLE would be the current TUPLE class). Therefore TUPLE could be conformed to V_SEQUENCE and V_MUTABLE_TUPLE conformed to V_ARRAY. Note that only the readonly interface could be in the Eiffel Standard.

In V_CONTAINER class only two features should use the variant typing:
<e>
new_cursor: V_ITERATOR [G]
do ... end

occurrences (v: variant G): INTEGER
do
-- G -> ANY then 'v' type = ANY
across Current as it loop
if it.item = v then
Result := Result + 1
end
end
end

has (v: variant G)
local
it: like new_cursor
do
-- G -> ANY then 'v' type = ANY
it := new_cursor -- 'it' type = V_ITERATOR [ANY]
it.search_forth (v)
Result := not it.after
ensure
occurrences (v) = 1
end
</e>

In V_ITERATOR only two features should use the variant typing without object test!

With these changes the next code is valid:
<e>
local
a: V_CONTAINER [ANY]; b: V_CONTAINER [STRING]
do
a := b

end
</e>

==== Sub-conclusion ====
With a right abstraction and a smart use of variant typing for generics, it is possible to obtain a greater flexibility keeping a fully aivailable interface.

=== Limit changes ===
To limit code change and to increase typing consistency, we can change the semantic of 'variant'.

Covariant redefinition of request result is not very useful.
The variant typing could be limited for covariant redefinition. There could have no effect on request result.

For generic conformance, a formal generic prefixed with the variant mark is covariant. The variant mark is not required on feature argument limiting code change.

However we have a problem: How mark a contravariant generic? There is two options:
* Another mark.
* No prefixed mark means novariant or contravariant generic

=== Export status restrictions ===
Since the ECMA Eiffel Standard forbids the export restriction with conforming inheritance, it is not a problem.
However, the semantic can be changed to enable this restriction on conforming inheritance.

Restrict exportation should not cause a catcall. The mechanism could be used just to change the class interface.
<e>
deferred class
ANIMAL
feature
is_vegetarian: BOOLEAN
deferred end
end
</e>
<e>
class
COW
inherit
ANIMAL
export {NONE}
is_vegetarian
end
feature {NONE}
is_vegetarian: BOOLEAN = True
end
</e>
<e>
local
an_animal: ANIMAL; a_cow: COW
b: BOOLEAN
do
create a_cow
b := a_cow.is_vegetarian -- invalid call

an_animal := a_cow
b := an_animal .is_vegetarian -- valid call
end
</e>

The class interface is more simple and readable.

== Conclusion ==
The proposition uses no new keyword and solves the catcall problem.
It passes all [[Catcall checkpoints]].

The new generic conformance gives a natural safe and flexible static typing.
The variant typing enables to create adaptive interfaces keeping a safe static typing.

With a fine abstraction and the use of variant typing for generics, the genric conformance flexibility is little restricted. The contravariant for request result can then be discarded for simplicity.

There is no interface restriction ([[Interval types]] or [[Usage-site variance]]). Class interfaces are fully available.

== Your view ==
name:
comment:

...

Immutable Interface

2013-08-29T12:43:20Z

Conaclos: Minor corrections

[[Category:ECMA]]
[[Category:Immutability]]
{{Research}}
== Introduction ==
Eiffel Base 2 relies on partial (see below) immutable interfaces to design better abstractions and to allow a better use of the library.
This page sketch a solution to allow full immutable interface designs.

== Definition ==
An interface is immutable if it exports only queries. The routines exported to no classes are not included in the class interface.
Note that an immutable class has an immutable interface and more queries must be pure, i.e. with no side-effect.

== Issue ==
Immutable interfaces are not conceivable in the current state of the Eiffel Standard.
Indeed, all classes inherit of ANY. However ANY has not an immutable interface, it exports some commands. Therefore no immutable interface is conceivable.

ANY class interface (queries are omitted):
<e>
class interface
ANY

feature -- Duplication

copy (other: like Current)
-- Update current object using fields of object attached
-- to `other', so as to yield equal objects.
require
type_identity: same_type (other)
ensure
is_equal: Current ~ other

frozen deep_copy (other: like Current)
-- Effect equivalent to that of:
-- copy (`other' . deep_twin)
ensure
deep_equal: deep_equal (Current, other)

feature -- Basic Operations

default_rescue
-- Process exception for routines with no Rescue clause.
-- (Default: do nothing.)

frozen do_nothing
-- Execute a null action.

feature -- Output

print (o: detachable ANY)
-- Write terse external representation of `o'
-- on standard output.

end
</e>

== Make ANY as immutable interface ==
=== Export commands to no classes ===
* The command 'default_rescue' allows to change an internal behavior. This command can be exported to no classes.

* The command 'do_nothing' is a procedure specially interesting for agent uses.
A qualified call of 'do_nothing' on any objects is not useful. An interesting use can be:
<e>
class
EXAMPLE

feature

do_something
do
do_something_with (agent {A}.do_nothing)
end

do_something_with (a: PROCEDURE [ANY, TUPLE [A]])
do end

end
</e>

However the contravariance (concept not introduced yet) of the second generic parameter of PROCEDURE can remove this use:
<e>
class
EXAMPLE

feature

do_something
do
do_something_with (agent do_nothing)
end

do_something_with (a: PROCEDURE [ANY, TUPLE [A]])
do end
</e>

Therefore the command 'do_nothing' can be exported to no classes.

* The command 'print' can be called only with unqualified calls. It can be too exported to no classes.

* The commands 'copy' and 'deep_copy' are probably used mainly through the queries 'twin' and respectively 'deep_twin'.
Export this commands to no classes seems have no important disturbance. It is always possible to export its in descendants.

However, we can easily imagine that 'twin' and 'deep_twin' create a new object and then apply 'copy' and respectively 'deep_copy'.
This process does not follow the Eiffel creation philosophy.
Maybe it is an opportunity to correct it and then to write the queries 'twin' and 'deep_twin' with Eiffel code.

A solution would be to make both commands as creation commands.
<e>
class
ANY

create
copy,
deep_copy,
default_create

feature {NONE}-- Initialization

copy (other: like Current)
-- Update current object using fields of object attached
-- to `other', so as to yield equal objects.
require
type_identity: same_type (other)
external
"built_in"
ensure
is_equal: Current ~ other
end

-- ...

feature -- Duplication

frozen twin: like Current
-- New object equal to `Current'
-- `twin' calls `copy'; to change copying/twinning semantics, redefine `copy'.
do
create Result.copy (Current)
ensure
is_equal: Result ~ Current
end

-- ...

end
</e>
The both commands can be exported to no classes and two queries can be writed in Eiffel code.
However the developer must declare the creation commands for each effective class.

To remove this issue we can introduce the inherited creation command mechanism.

=== Inherited Creation Command ===
A simple addition to Eiffel could be to allow the create clause in the deferred classes.
The creation commands declared in deferred classes would be inherited creation commands, i.e. creation commands implicitly declared in each descendants.

If an effective class declares no new creation commands then all inherited creation commands and the command 'default_create' are creation commands.
If an effective class declares new creation commands then all inherited creation commands and new ones are creation commands.
An inherited command can be declared again in an effective class. This possibility allows then all inherited commands as creation commands without 'default_create' (except if 'default_create' is an inherited creation command).

<e>
deferred class
A

create -- inherited
make

feature -- Initialization

make (a_n: INTEGER)
deferred end

end
</e>
<e>
class
B

inherit
A

feature
-- 'make' and 'default_create' are creation procedures

end
</e>
<e>
class
C

inherit
A

create
make

feature
-- 'make' is a creation procedure

end
</e>

This addition does not affect existing code. The compatibility is preserved.
And more it can be useful in constrained generic context.

=== ANY and inherited creation commands ===
The mechanism described in the previous section is not usable on ANY. Indeed, ANY is an effective class.
However it is very useful to allow the creation of ANY instance?

I have no example of use of ANY instances. Maybe it is more relevant to make ANY as deferred class and then to use the inherited creation command mechanism.

<e>
deferred class
ANY

create -- inherited creation commands
copy,
deep_copy

feature
-- ...

end
</e>

== Conclusion ==
Export all ANY class's commands allows the design of full immutable interfaces.

In addition, the inherited creation command concept is a minimal mechanism compatible with existing software. It introduces no new keyword and allows to write two queries of ANY in Eiffel code.

EiffelStudio Wish List

2013-08-23T22:18:32Z

Conaclos: Anchror replacement proposal

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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.
|| ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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
</code>
equivalent to:
<code>
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
|
|

|-
! Iterable 'TUPLE'
| Allow to use an iterator on TUPLE.
|
|
|

|-
! Customized creation procedure for expanded type
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
* Assigner Commands are not droped when the procedure is renamed.
* Assigner Commands are not droped when the procedure is renamed or redefined.
* When a request 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.
"[]", "<>", "()", "{}"
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2013-08-22T15:07:35Z

Conaclos: new features for NATURAL

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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.
|| ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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
</code>
equivalent to:
<code>
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
|
|

|-
! Iterable 'TUPLE'
| Allow to use an iterator on TUPLE.
|
|
|

|-
! Customized creation procedure for expanded type
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
* Assigner Commands are not droped when the procedure is renamed.
* Assigner Commands are not droped when the procedure is renamed or redefined.
* When a request 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.
"[]", "<>", "()", "{}"
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! 'factorial', 'even' and 'odd' request
| Add features to NATURAL types.
<e>
factorial: like Current
...

even: BOOLEAN
...

odd: BOOLEAN
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

Category:Immutability

2013-08-20T12:10:51Z

Conaclos: Category description

Pages about immutability concepts for Eiffel.

DynamicTypeSet

2013-08-19T16:35:24Z

Conaclos: Remove 'is' keyword

[[Category:ECMA]]
Author: Matthias Konrad

{{UnderConstruction}}

====CAT-Call freeness detection algorithms====
Finding out, whether any given Eiffel system contains a CAT call is undecidable. A CAT call finding algorithm will thus make one or both of the following error kinds:
* Kind A: Report a system that has no CAT-call as NOT CAT-call free.
* Kind B: Report a system containing CAT-calls as CAT-call free.
Algorithms making errors of kind B are of no use. An algorithm that only makes errors of kind A leads to type safety, but may be useless if it makes too many (the trivial algorithm, that reports every Eiffel system as NOT CAT-call free makes no errors of kind B but is completely useless).
The goal is thus to find the maximal (or most reasonable) subclass of the class of CAT-call free Eiffel systems that is decidable and fast enough to be used in practice.

====Dynamic type set algorithm====
The Dynamic type set algorithm (DTSA) as defined in ETL2 (combined with a system validity check) seems to make no errors of kind B (it remains to be proven) but certainly of kind A. By showing some of these errors we try to show what impact the DTSA has to the Eiffel language.

DTSA does not work well with generic algorithms. See feature ''merge'', that merges the list ''f'' into the list ''t'':

<code>[eiffel, N]
merge (f, t: LIST [ANY])
require
f /= Void
t /= Void
--f.G <= t.G
do
from f.start until f.after loop
t.extend (f.item)
f.forth
end
end
</code>

This feature might be used frequently in a bigger system. As a consequence, the dynamic type sets of both arguments become large. It is not the performance problem that interests us here, but the fact that the feature will become invalid very fast. A system containing the following two calls to ''merge'' (even if the calls are not in the same feature or even class) will be reported as invalid:

<code>[eiffel, N]
merge (create {LINKED_LIST [STRING]}.make, create {LINKED_LIST [STRING]}.make)
merge (create {LINKED_LIST [ANY]}.make, create {LINKED_LIST [ANY]}.make)
</code>

I consider this a strong error of kind A, since it obviously takes power (genericity) from the language.

====Why does the DTSA fail for the merge methode====
==Proof obligation based algorithm==

Feature ''merge'' works with lots of dynamic types. It depends on one thing tough, the actual generic parameter of argument ''f'' needs to be equally or more specific compared to the actual generic parameter of argument ''t''. This constraint should be detected by an algorithm and made an obligation for every caller of ''merge''. In Eiffel an obligation made to a caller is a precondition.

====Rule 1====
For calls of the form:

<code>
t.f (a)
</code>
where feature the first formal argument of feature ''f'' is of generic type G the following obligation follows:
a <= t.G, a needs to be more specific than the

A better algorithm should detect what feature ''merge'' depends on to work properly.

One weakness of the DTSA is, that the dynamic type sets of arguments of often used types become huge. This indirectly leads to many errors of kind A as the following example shows:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<e>
foo
local
l1: LIST_ANY
l2: LIST_STRING
do
create l1
l1.put ("")
double_list (l1)

create l2
l2.put ("")
double_list (l2)
end
</e>
|
<e>
double_list (l: LIST_ANY) -- backward obligation: l.put.item >= l.item
do
l.put (l.item)
end

merge_list (from_list, to_list: LIST_ANY) --backward obligation: to_list.put.item >= from_list.start
do
to_list.put (from_list.start)
end

add_to_list (list: LIST_ANY; elem: ANY) --backward obligation: list.put.item >= elem
do
list.put (elem)
end

</e>
|}

The dynamic type set of argument ''i'' of feature ''put'' of type ''LIST_ANY'' becomes {INTEGER, STRING}. Same thing for attribute ''item'' of type ''LIST_ANY''. DTSA will thus fail to report this system as CAT-call free.

The following system will be used for examples:

{|border="0" cellpadding="2" cellspacing="0" align="center"
|-valign="top" -halign="center"
|
<code>[eiffel,N]
class
LIST_ANY
feature
put (i: ANY) is
do
item := i
end
item: ANY
end
</code>
|
<code>[eiffel,N]
class
LIST_STRING
inherit
LIST_ANY
redefine put, item end
feature
put (i: STRING) is
do
item := i
end
item: STRING
end
</code>
|}

Immutable Interface

2013-08-19T13:36:35Z

Conaclos: tag correction

[[Category:ECMA]]
[[Category:Immutability]]
{{Research}}
== Introduction ==
Eiffel Base 2 relies on immutable interfaces to design better abstractions and to allow a better use of the library.
This page sketch a solution to allow immutable interface designs.

== Definition ==
An interface is immutable if it exports only queries. The routines exported to no classes are not included in the interface.
Note that an immutable class has an immutable interface. However queries must be pures, i.e. with no side-effect.

== Issue ==
Immutable interfaces are not conceivable in the current state of the Eiffel Standard.
Indeed, all classes inherit of ANY. However ANY exports some commands. Therefore no immutble interface is conceivable.

ANY commands:
<e>
class interface
ANY

feature -- Duplication

copy (other: like Current)
-- Update current object using fields of object attached
-- to `other', so as to yield equal objects.
require
type_identity: same_type (other)
ensure
is_equal: Current ~ other

frozen deep_copy (other: like Current)
-- Effect equivalent to that of:
-- copy (`other' . deep_twin)
ensure
deep_equal: deep_equal (Current, other)

feature -- Basic Operations

default_rescue
-- Process exception for routines with no Rescue clause.
-- (Default: do nothing.)

frozen do_nothing
-- Execute a null action.

feature -- Output

print (o: detachable ANY)
-- Write terse external representation of `o'
-- on standard output.

end
</e>

== Make ANY as immutable interface ==
=== Export commands to no classes ===
* The command 'default_rescue' allows to change an internal behavior. This command can be exported to no classes.

* The command 'do_nothing' is a procedur especially interresting for agent uses.
A qualified call of 'do_nothing' on any objects is not usefull. An interresting use can be:
<e>
class
EXAMPLE

feature

do_something
do
do_something_with (agent {A}.do_nothing)
end

do_something_with (a: PROCEDURE [ANY, TUPLE [A]])
do end

end
</e>

However the contravariance of the second generic parameter of PROCEDURE can remove this use:
<e>
class
EXAMPLE

feature

do_something
do
do_something_with (agent do_nothing)
end

do_something_with (a: PROCEDURE [ANY, TUPLE [A]])
do end
</e>

Therefore the command 'do_nothing' can be exported to no classes.

* The command 'print' can be called only with unqualified calls. It can be too exported to no classes.

* The commands 'copy' and 'deep_copy' give us a challenge. Indeed they are used in queries ('twin' and 'deep_twin').
We can note that they are mainly used to initialize a freshly created object.

We can imagine that 'twin' and 'deep_twin' create a new object and then apply 'copy' or respectively 'deep_copy'.
This process does not folow the Eiffel creation phillosophy.
Maybe it is an opportunity to correct it and then to concretise the queries 'twin' and 'deep_twin' with Eiffel code.

A solution would be to make both commands as creation commands.
<e>
class
ANY

create
copy,
deep_copy,
default_create

feature {NONE}-- Duplication

copy (other: like Current)
-- Update current object using fields of object attached
-- to `other', so as to yield equal objects.
require
type_identity: same_type (other)
external
"built_in"
ensure
is_equal: Current ~ other
end

-- ...

feature -- Duplication

frozen twin: like Current
-- New object equal to `Current'
-- `twin' calls `copy'; to change copying/twinning semantics, redefine `copy'.
do
create Result.copy (Current)
ensure
is_equal: Result ~ Current
end

-- ...

end
</e>
The both commands can be exported to no classes and two queries can be writed in Eiffel code.
However the developper must declare the creation commands for ecah effective class.

To remove this issue we can introduce the inherited creation commands.

=== Inherited creation commands ===
A simple addition to Eiffel could be to allow the create clause in the deferred classes.
The creation commands declared in deferred classes would be inherited creation commands.

<e>
deferred class
A

create -- inherited
make

feature -- Initialization

make (a_n: INTEGER)
do end

end
</e>
<e>
class
B

inherit
A

create
-- make is a creation procedure

end
</e>

This addition does not affect existing code. The compatibility is preserved.
And more it can be usefull in constrained generic context.

=== ANY and inherited creation commands ===
The mechanism described in the previous section is not usable on ANY. Indeed, ANY is an effetcive class.
However it is very usefull to allow the creation of ANY instance?

I have no example of use of ANY instances. Maybe it is more relevant to make ANY as deferred class and then to use the inherited creation command mechanism.

<e>
deferred class
ANY

create -- inherited creation commands
copy,
deep_copy

feature
-- ...

end
</e>

== Conclusion ==
The proposition allows the design of full immutable interfaces.

The inherited creation command is a minimal mechanism compatible with existing software. It introduces no new keyword.
it allow to concretise two querise of ANY in Eiffel code and to export to no classes two problematic commands.

Immutable Interface

2013-08-19T13:33:04Z

Conaclos: Page creation

[[Category:ECMA]]
[[Category:Immutability]]
{{Research}}
== Introduction ==
Eiffel Base 2 relies on immutable interfaces to design better abstractions and to allow a better use of the library.
This page sketch a solution to allow immutable interface designs.

== Definition ==
An interface is immutable if it exports only queries. The routines exported to no classes are not included in the interface.
Note that an immutable class has an immutable interface. However queries must be pures, i.e. with no side-effect.

== Issue ==
Immutable interfaces are not conceivable in the current state of the Eiffel Standard.
Indeed, all classes inherit of ANY. However ANY exports some commands. Therefore no immutble interface is conceivable.

ANY commands:
<e>
class interface
ANY

feature -- Duplication

copy (other: like Current)
-- Update current object using fields of object attached
-- to `other', so as to yield equal objects.
require
type_identity: same_type (other)
ensure
is_equal: Current ~ other

frozen deep_copy (other: like Current)
-- Effect equivalent to that of:
-- copy (`other' . deep_twin)
ensure
deep_equal: deep_equal (Current, other)

feature -- Basic Operations

default_rescue
-- Process exception for routines with no Rescue clause.
-- (Default: do nothing.)

frozen do_nothing
-- Execute a null action.

feature -- Output

print (o: detachable ANY)
-- Write terse external representation of `o'
-- on standard output.

end
</e>

== Make ANY as immutable interface ==
=== Export commands to no classes ===
* The command 'default_rescue' allows to change an internal behavior. This command can be exported to no classes.

* The command 'do_nothing' is a procedur especially interresting for agent uses.
A qualified call of 'do_nothing' on any objects is not usefull. An interresting use can be:
<e>
class
EXAMPLE

feature

do_something
do
do_something_with (agent {A}.do_nothing)
end

do_something_with (a: PROCEDURE [ANY, TUPLE [A]])
do end

end
</e>

However the contravariance of the second generic parameter of PROCEDURE can remove this use:
<e>
class
EXAMPLE

feature

do_something
do
do_something_with (agent do_nothing)
end

do_something_with (a: PROCEDURE [ANY, TUPLE [A]])
do end
</e>

Therefore the command 'do_nothing' can be exported to no classes.

* The command 'print' can be called only with unqualified calls. It can be too exported to no classes.

* The commands 'copy' and 'deep_copy' give us a challenge. Indeed they are used in queries ('twin' and 'deep_twin').
We can note that they are mainly used to initialize a freshly created object.

We can imagine that 'twin' and 'deep_twin' create a new object and then apply 'copy' or respectively 'deep_copy'.
This process does not folow the Eiffel creation phillosophy.
Maybe it is an opportunity to correct it and then to concretise the queries 'twin' and 'deep_twin' with Eiffel code.

A solution would be to make both commands as creation commands.
<e>
class
ANY

create
copy,
deep_copy,
default_create

feature {NONE}-- Duplication

copy (other: like Current)
-- Update current object using fields of object attached
-- to `other', so as to yield equal objects.
require
type_identity: same_type (other)
external
"built_in"
ensure
is_equal: Current ~ other
end

-- ...

feature -- Duplication

frozen twin: like Current
-- New object equal to `Current'
-- `twin' calls `copy'; to change copying/twinning semantics, redefine `copy'.
do
create Result.copy (Current)
ensure
is_equal: Result ~ Current
end

-- ...

end
</e>
The both commands can be exported to no classes and two queries can be writed in Eiffel code.
However the developper must declare the creation commands for ecah effective class.

To remove this issue we can introduce the inherited creation commands.

=== Inherited creation commands ===
A simple addition to Eiffel could be to allow the create clause in the deferred classes.
The creation commands declared in deferred classes would be inherited creation commands.

<e>
deferred class
A

create -- inherited
make

feature -- Initialization

make (a_n: INTEGER)
do end

end
</e>
<e>
class
B

inherit
A

create
-- make is a creation procedure

end
</e>

This addition does not affect existing code. The compatibility is preserved.
And more it can be usefull in constrained generic context.

=== ANY and inherited creation commands ===
The mechanism described in the previous section is not usable on ANY. Indeed, ANY is an effetcive class.
However it is very usefull to allow the creation of ANY instance?

I have no example of use of ANY instances. Maybe it is more relevant to make ANY as deferred class and then to use the inherited creation command mechanism.

<e>
deferred class
ANY

create -- inherited creation commands
copy,
deep_copy

feature
-- ...

end
<e/>

== Conclusion ==
The proposition allows the design of full immutable interfaces.

The inherited creation command is a minimal mechanism compatible with existing software. It introduces no new keyword.
it allow to concretise two querise of ANY in Eiffel code and to export to no classes two problematic commands.

EiffelStudio Wish List

2013-07-27T10:03:25Z

Conaclos: Remove the example

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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.
|| ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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
</code>
equivalent to:
<code>
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
|
|

|-
! Iterable 'TUPLE'
| Allow to use an iterator on TUPLE.
|
|
|

|-
! Customized creation procedure for expanded type
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
* Assigner Commands are not droped when the procedure is renamed.
* Assigner Commands are not droped when the procedure is renamed or redefined.
* When a request 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.
"[]", "<>", "()", "{}"
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! Factorial request
| Add factorial feature to NATURAL types.
<e>
factorial alias "!": like Current
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2013-07-27T10:01:01Z

Conaclos: Syntax correction

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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.
|| ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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
</code>
equivalent to:
<code>
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
|
|

|-
! Iterable 'TUPLE'
| Allow to use an iterator on TUPLE.
|
|
|

|-
! Customized creation procedure for expanded type
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
* Assigner Commands are not droped when the procedure is renamed.
* Assigner Commands are not droped when the procedure is renamed or redefined.
* When a request 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.
"[]", "<>", "()", "{}"

A possible application :
<e>
class
PROCEDURE [BASE_TYPE, OPEN_ARGS -> detachable TUPLE create default_create end]

feature -- Calls
call alias "()" (args: detachable OPEN_ARGS)
...

end
</e>
<e>
do_something (p: PROCEDURE [ANY,TUPLE [NATURAL]]
do
p ([8]) -- equivalent to p.call ([8])
end
</e>
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! Factorial request
| Add factorial feature to NATURAL types.
<e>
factorial alias "!": like Current
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2013-07-27T10:00:07Z

Conaclos: Add syntax coloration

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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.
|| ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<e>
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
</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
</code>
equivalent to:
<code>
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
|
|

|-
! Iterable 'TUPLE'
| Allow to use an iterator on TUPLE.
|
|
|

|-
! Customized creation procedure for expanded type
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<e>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</e>
equivalent to:
<e>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</e>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
* Assigner Commands are not droped when the procedure is renamed.
* Assigner Commands are not droped when the procedure is renamed or redefined.
* When a request 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.
"[]", "<>", "()", "{}"

A possible application :
<e>
class
PROCEDURE [BASE_TYPE, OPEN_ARGS -> detachable TUPLE create default_create end]

feture -- Calls
call alias "()" (args: detachable OPEN_ARGS)
...

end
</e>
<e>
do_something (p: PROCEDURE [ANY,TUPLE [NATURAL]]
do
p ([8]) -- equivalent to p.call ([8])
end
</e>
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! Factorial request
| Add factorial feature to NATURAL types.
<e>
factorial alias "!": like Current
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2013-07-27T09:57:50Z

Conaclos: Enclosed alias proposal

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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.
|| ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<code>
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
</code>
|
|
|

|-
! 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.:
<code>
foo( a : B): C
exceptions
Net_Unreachable, Net_Timeout
do
Result := values.item ("foo")
end
</code>
|| 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'''
<code>
a_routine
do
across 1 |..| 10
loop
-- do something
end
end
</code>
|
|
|

|-
! Simple conversion declaration
| Allow to write a simple conversion statment:
<code>
class
CONVERSION_PROPOSAL

create
make_from

convert
make_from,
something

feature
make_from (v: A_TYPE)
do end

something: ANOTHER_TYPE
do end

end
</code>
equivalent to:
<code>
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
</code>
| Esaier and more readable declaration
|
|

|-
! Iterable 'TUPLE'
| Allow to use an iterator on TUPLE.
|
|
|

|-
! Customized creation procedure for expanded type
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<code>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</code>
equivalent to:
<code>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</code>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
* Assigner Commands are not droped when the procedure is renamed.
* Assigner Commands are not droped when the procedure is renamed or redefined.
* When a request 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:
<code>
class
A

feature {B, C} -- Access
q: A assign c

feature {C, D} -- Chnage
c (v: A)
do
q := v
end

end
</code>
<code>
-- o: A
o.q := v
</code>
is allowed in classes conforms to 'C'.
|
|
|

|-
! Enclosed alias
| Enclosed alias has similar behavior to bracket alias.
"[]", "<>", "()", "{}"

A possible application :
<code>
class
PROCEDURE [BASE_TYPE, OPEN_ARGS -> detachable TUPLE create default_create end]

feture -- Calls
call alias "()" (args: detachable OPEN_ARGS)
...

end
</code>
<code>
do_something (p: PROCEDURE [ANY,TUPLE [NATURAL]]
do
p ([8]) -- equivalent to p.call ([8])
end
</code>
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! Factorial request
| Add factorial feature to NATURAL types.
<e>
factorial alias "!": like Current
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

EiffelStudio Wish List

2013-05-26T10:30:49Z

Conaclos: factorial and abs requests

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

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 ===
{| class="wikitable"
!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 [http://intentsoft.com/]
|-
! 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?). || || ||

|}

=== .NET ===
{| class="wikitable"
!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 ==
{| class="wikitable"
!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, [http://secure.ucd.ie/products/opensource/ESCJava2/ ESC/Java2] and the associated Eclipse plugin, or Spec# integration into VisualStudio [http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/MikeBarnett-SpecSharp.wmv]. Eiffel has most of the necessary language constructs already and doesn't require annotations. See also [http://fm06.mcmaster.ca/es-verify.pdf 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.
|| ||

|}

== Language ==
{| class="wikitable"
!ID !! Short Summary !! Pros !! Cons !! More info

|-
! XXX
| Allow to use '''?''' in assigner declaration For instance
<code>
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
</code>
|
|
|

|-
! 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.:
<code>
foo( a : B): C
exceptions
Net_Unreachable, Net_Timeout
do
Result := values.item ("foo")
end
</code>
|| 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'''
<code>
a_routine
do
across 1 |..| 10
loop
-- do something
end
end
</code>
|
|
|

|-
! Simple conversion declaration
| Allow to write a simple conversion statment:
<code>
class
CONVERSION_PROPOSAL

create
make_from

convert
make_from,
something

feature
make_from (v: A_TYPE)
do end

something: ANOTHER_TYPE
do end

end
</code>
equivalent to:
<code>
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
</code>
| Esaier and more readable declaration
|
|

|-
! Iterable 'TUPLE'
| Allow to use an iterator on TUPLE.
|
|
|

|-
! Customized creation procedure for expanded type
| Require 'default_create' as now but allow to use another creation procedure.
|
|
|

|-
! Empty braces for unexported features
|
<code>
class
PROPOSITION

feature {}
internal_something: A_TYPE
do end

end
</code>
equivalent to:
<code>
class
CURRENT_STANDARD

feature {NONE}
internal_something: A_TYPE
do end

end
</code>
|
* Liberty Eiffel uses this syntax.
* NONE keyword could be deprecated in the future (save a keyword and remove the concept of a class NONE inheriting of all classes)
|
* The proposal <code>{}</code> is less explicit, so it is arguably harder to read than the current standard <code>{NONE}</code>.
* The proposal <code>{}</code> is likely to cause confusion between unexported features and features exported to <code>{ANY}</code>. Empty braces look very similar to braces omitted entirely.
* The proposal would force upgrading of existing code, which would be disruptive to existing users (although probably easily automated).
* What about <code>inherit {NONE}</code>?
* What would the type of <code>Void</code> be?
|

|-
! 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.
* Assigner Commands are not droped when the procedure is renamed.
* Assigner Commands are not droped when the procedure is renamed or redefined.
* When a request 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:
<code>
class
A

feature {B, C} -- Access
q: A assign c

feature {C, D} -- Chnage
c (v: A)
do
q := v
end

end
</code>
<code>
-- o: A
o.q := v
</code>
is allowed in classes conforms to 'C'.
|
|
|

|}

== 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:
where (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
--returns container like current, for items satisfying test
deferred
end
|
|
|

|-
! slice functions
|
slice_until, slice_after, slice_after_and_including, etc (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): like Current
deferred
end
|
|
|

|-
! Absolute request result as NATURAL
| Change the 'abs' request type.
<e>
abs: NATURAL_32
-- (from INTEGER_32_REF)
...
</e>
|
|
|

|-
! Factorial request
| Add factorial feature to NATURAL types.
<e>
factorial alias "!": like Current
...
</e>
|
|
|
|}

== Other ==
{| class="wikitable"
!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.
|| ||

|}

Persistence predicates

2013-05-20T15:13:32Z

Conaclos: remove 'is' keyword

[[Category:Persistence]]
{{Research}}
==Introduction==

Using <e>STORABLE</e>s in an application has at least two significant disadvantages.

One is that using them for long-term persistence is vulnerable to changes in the class.

Another is that too much data may be stored, resulting in large files (or database occupancy, or whatever) and slow reload times. Some data, such as internal caches, are probably best not serialized at all. For other data, it may be better just to store a shorthand identifier to enable the data to be rebuilt (maybe on demand) at retrieval time.

This article explores ways to address the second problem. The first problem is best tackled by only using <e>STORABLE</e>s as a medium-term caching mechanism.

==Transient data==

Java tackles this problem with the keyword <java>transient</java>. An attribute so marked is not stored at serialization time. When the object is retrieved the attribute will be void.

This seems rather limited to me. It can't be used if the class invariant constrains the attribute to be non-void. And I don't think there is a way for a descendant class to override this behaviour (it's a long time since I've written any Java, so I could be very wrong here).

My thinking is that there should be a way to specify whether or not a particular attribute should be stored on any given occaision, and a way to specify what to do at retrieval time.

===Persistence predicates===

A persistence predicate is a routine of type <e>PREDICATE [ANY, TUPLE [!<attribute_type>]]</e> associated with an attribute of type <attribute_type>.
At storage time, the predicate will be called with the instance of the attribute as its argument (if the attribute is non-Void). If it returns <e>True</e> then the attribute is stored. If it returns <e>False</e> then the attribute is not stored, but it may be re-created at retrieval time.

===Restoration routines===

If a persistence predicate returns <e>False</e>, it may be that the programmer does not need this data at all (such as the case of an internal cache). But in some cases the programmer will want the data to be recreated at restoration time (this may be necessary to restore the class invariant), rather than retrieved from the persistence mechanism.

Take an example of a class which has an attribute named <e>`gadget'</e> of type <e>GADGET_FROM_DATABASE</e> having an attribute named <e>`id'</e> of type <e>INTEGER</e>. The class invariant requires that<e>`gadget'</e> is not <e>Void</e>, but the size required to store <e>`gadget'</e> is very large. The class also has a secret routine <e>`create_gadget_from_identifier (a_id: INTEGER)</e> which can be used to create a <e>GADGET_FROM_DATABASE</e> given its <e>`id'</e> value. In such a case, rather than store <e>`gadget'</e> it is probably better to just store the <e>`id'</e> value, and then call <e>`create_gadget_from_identifier'</e> at retrieval time.

A restoration routine is similar to a creation procedure, in as much as it cannot reply on the class invariant holding. It can rely on attributes for which the persistence predicate evaluates to <e>True </e> as having been restored, though.

==Syntax==

One new keyword <e>restore</e> will be required. This can occur in several places:

<ul>
<li>After the <e>create</e> clause in the class prolog. What follows is a list of restoration routines, just like the list of creation procedures. Typically this will occur in the form:
<e>
restore {STORABLE}
recreate_attributes
</e>
</li>
<li>After the <e>attribute</e> keyword and optional body. What follows is:

1. The tag <e>persistence_predicate:</e> followed by one of:

a) <e>True</e> meaning always persist.
b) <e>False</e> meaning never persist.
c) The keyword <e>agent</e> followed by a declaration of a <e>PREDICATE</e>.

2. An optional body (introduced by the tag <e>body:</e>) like the attribute body, and this is code that is executed only if the attribute was not persisted. These routines run after all persisted attributes have been restored, but before the restoration procedure is run. It is only used for initialization of attributes that do not depend
upon other restoration attribute bodies having been run.

</li>
<li>
Within a restoration routine as an instruction. Here it is used analagously to a <e>create</e> instruction, to run one of the named restoration routines specified in the class of one of the attributes that was not persisted.
</li>
</ul>

===Example===

<e>
class A

create
make, make_from_db

restore {STORABLE}
initialize_attributes, recreate_attributes

feature {NONE} -- Initialization

make
-- Initialize `Current' with a new gadget.
do
initialize_attributes
gadget.save_to_database
-- other stuff ...
end

make_from_db (a_gadget_id: INTEGER; ...)
-- Initialize `Current' using `a_gadget_id' to create `gadget' from database.
do
recreate_attributes (a_gadget_id, ...)
-- other stuff
end

initialize_attributes
-- Initialize `gadget' and ...
do
create gadget.make_new
-- other stuff ...
end

recreate_attributes (a_gadget_id: INTEGER; ...)
-- Recreate certain attributes.
do
create_gadget_from_identifier (a_gadget_id)
-- other stuff
end

feature -- Access

gadget: GADGET
-- Gadget retrieved from DB via its `id' attribute
attribute
restore
persistance_predicate: agent is_gadget_persisted (attribute.id) -- `True' and `False' would also be acceptable values,
-- with `True' being the default
body: agent create_gadget_from_identifier (attribute.id)
end

end

class B

inherit

A
redefine
make
rename
gadget as gadget_from_a
end

create

make

restore {STORABLE}

restore_gadgets

feature {NONE} -- Initialization

make
-- Initialize `Current' with a new gadget.
do
Precursor
create gadget.make_new
end

restore_gadgets (a_id, a_other_id: INTEGER; ...)
-- Restore `gadget' and `gadget_from_a' from database.
do
restore recreate_attributes (a_other_id, ...)
create gadget.make_from_databse (a_id)
end

feature -- Access

gadget: MY_GADGET
-- Gadget createable from database.
attribute
restore
persistance_predicate: False
end

end
</e>

Here the ECMA <e>attribute</e> keyword is reused to denote the instance of `gadget'. This is only available within the attribute restore clause, not in a restoration routine.

Now here are some scenarios in which objects of classes A and B are stored:

<e>
local
a: A
b: B
do
create a.make
create b.make

-- Save a to a storable, using defaults for retrieval
a.independent_store (a_medium)

-- Assuming `a.is_gadget_persisted (a.gadget.id)' returns `False', `a.gadget' will not be saved, but `a.gadget.id' will be saved
-- for use in the local (attribute-specified) restoration routine `create_gadget_from_identifier.

-- Save b to a storable specifying a restoration routine
b.independent_store (a_medium, agent b.restore_gadgets (b.gadget.id, b.gadget_from_a.id, ...))

-- Assuming `b.is_gadget_persisted (b.gadget_from_a.id)' returns `False', then neither gadget will be stored, but their identifiers
-- will be recorded so they can be passed to `restore_gadgets' at retrieval time.
</e>

==Redefinition==

The open/closed principle is honoured (I think). The author of the class can determine that an attribute must always be stored (this is the default, and is the current situation), or that it is never stored (for a pure cache attribute), or provide flexibility by specifying an agent.

The agent's routine could be deferred, frozen (yuk!) or just a normal routine, in which case descendant classes can redefine it.

The actual instance data that is passed to the persistance_predicate and the restoration_routine could be specified via an agent, which allows for further flexibility. For restoration, it might even involve an <e>EV_DIALOG</e> (heaven forfend)!

==Class correctness conditions==

The possibility of the persistance_predicate evaluating to (or statically specified as) <e>False</e> on an attribute that is required to be non-Void (or non-default for an expanded attribute) implies that either inline restoration code must be supplied, or the restoration routine has an appropriate postcondition clause.

Persistence code samples

2013-05-20T15:11:40Z

Conaclos: apply void-safety and style guide

[[Category:Persistence]]
Below are sketches of essential classes of the PERSIST framework.

For an open discussion on the design choices please have a look at the [[persistence framework design discussion]].

You can download the source code here (TODO: provide a link to the sources)

An example of an actually implemented library built according to the PERSIST framework is [http://dadle.origo.ethz.ch/wiki/documentation_of_the_library dadle].

You can also go back to the [[persistence unified]] page.
==Simplified BON diagram==

[[Image:Abel_class_diagram.png]]

==PERSISTENCE_MANAGER==
<e>
class
PERSISTENCE_MANAGER

feature -- Access

medium: PERSISTENCE_MEDIUM
-- Chosen medium

format: PERSISTENCE_FORMAT
-- Chosen format

feature -- Basic operations

store (an_object: ANY)
-- Persists an_object using the format and medium stored by current object.
do
format.store (an_object, medium)
end

retrieve: ANY
-- Retrieves an_object using the medium and format stored by current object.
do
Result := format.retrieve (medium)
end

end
</e>

==BINARY_PERSISTENCE_MANAGER==
<e>
class
BINARY_PERSISTENCE_MANAGER

inherit
PERSISTENCE_MANAGER

create
make

feature -- Initialization

make (file_name: STRING)
-- Initialization procedure
do
create {FILE_MEDIUM} medium.make (file_name)
create {INDEPENDENT_BINARY_FORMAT} format
end

end
</e>

==PERSISTENCE_FORMAT==
<e>
deferred class
PERSISTENCE_FORMAT

feature -- Basic operations

serialized_form: SERIALIZED_FORM
-- Desired serialized form. If exists, this is what will be serialized.

set_serialized_form (custom_serialized: SERIALIZED_FORM)
-- Set desired custom serialized form. This is what will be serialized.
do
serialized_form := custom_serialized
ensure
object_effect: custom_ser = serialized_form
end

store (object: ANY; medium: PERSISTENCE_MEDIUM)
-- Store 'object' using medium
deferred
end

retrieve (medium: PERSISTENCE_MEDIUM):ANY
deferred
end
end
</e>

==BINARY_FORMAT==

<e>
deferred class
BINARY_FORMAT

inherit
PERSISTENCE_FORMAT
redefine
store,
retrieve
end

feature -- Access

store_handler: SED_STORABLE_FACILITIES

serializer: SED_MEDIUM_READER_WRITER

feature -- Basic operations

store (object: ANY; data_file: FILE_MEDIUM)
-- stores 'object' using a FILE_MEDIUM
do
create store_handler
create serializer.make (data_file.raw_file)
if data_file.exists then
data_file.reopen_write (data_file.file_name)
else
data_file.open_write
end
serializer.set_for_writing
store_now (object)
end

store_now (object_to_store: ANY)
-- Proper store operation depends on specific descendant.
deferred
end

retrieve (data_file: FILE_MEDIUM): ANY
-- Retrieve object using a FILE_MEDIUM
do
create store_handler
create serializer.make (data_file.raw_file)
if data_file.exists then
data_file.open_read
serializer.set_for_reading
Result:= store_handler.retrieved (serializer,true)
else
print ("%NData file does not exist! ")
end
end

end
</e>

==INDEPENDENT_BINARY_FORMAT==
<e>
class
INDEPENDENT_BINARY_FORMAT

inherit
BINARY_FORMAT

feature -- Access

optimized_for_retrieval: BOOLEAN

feature -- Status setting

set_optimized_for_retrieval (is_optimized_for_retrieval:BOOLEAN)
do
optimized_for_retrieval:= is_optimized_for_retrieval
ensure
optimized_for_retrieval_effect: optimized_for_retrieval = is_optimized_for_retrieval
end

feature -- Basic operations

store_now (object_to_store:ANY)
do
store_handler.independent_store(object_to_store,serializer,optimized_for_retrieval)
end

end
</e>

==FILE_MEDIUM==
<e>
class
FILE_MEDIUM

inherit
PERSISTENCE_MEDIUM

create
make

feature -- Initialization

make (a_file_name:STRING)
do
create raw_file.make (a_file_name)
file_name:=a_file_name
ensure
file_name_effect: file_name = a_file_name
end

feature -- Access

raw_file: RAW_FILE

file_name: STRING

feature -- Status report

exists: BOOLEAN
do
Result := raw_file.exists
end

feature -- Basic operations

reopen_write (a_file_name: STRING)
-- Reopens the file named 'a_file_name' for writing.
do
raw_file.reopen_write (a_file_name)
end

open_write
-- Open the current file for writing.
do
raw_file.open_write
end

open_read
-- Open the current file for reading.
do
raw_file.open_read
end

end
</e>