[[Category:ECMA]]
[[Category:Catcall]]
== Introduction ==

The usage-site variance allows the programmer to choose which kind of variance he wants to use when a generic derivation is declared. This allows to use every generic as novariant, covariant or contravariant in contrast to the [[definition-site variance]] where it is set in the class definition.

== Syntax ==

The syntax used here to specify the variance of a generic is simple and may be changed to something more verbose but also clearer:

* To specify a novariant generic, the normal syntax can be used: <e>LIST [ANY]</e>
* To specify a covariant generic, we use a plus sign: <e>LIST [+ANY]</e>
* To specify a contravariant generic, we use a minus sign: <e>LIST [-ANY]</e>

== Semantics ==

See the [[introduction to examples]] for information about the classes used.

=== Conformance rules ===

Depending on the variance of the generic, the conformance rules differ:

* A generic conforms to a novariant generic if it has the exact same generic parameter. Thus <e>LIST [T]</e> only conforms to <e>LIST [T]</e>. Note that <e>LINKED_LIST [T]</e> also conforms to <e>LIST [T]</e> as long as the generic parameter matches.
* A generic conforms to a covariant generic if its generic parameter conforms to the generic parameter of the covariant generic. Thus <e>LIST [U]</e> conforms to <e>LIST [+T]</e>.
* A generic conforms to a contravariant generic if its generic parameter is a parent of the generic parameter of the contravariant generic. Thus <e>LIST [T]</e> conforms to <e>LIST [-U]</e>.

For the conformance of tuples, we keep that a tuple with more elements conforms to a tuple with less elements as long as the common elements conform:

* <e>TUPLE [T, U]</e> conforms to <e>TUPLE [T]</e>
* <e>TUPLE [U, U]</e> conforms to <e>TUPLE [+T]</e>
* <e>TUPLE [T, U]</e> conforms to <e>TUPLE [-U]</e>

=== Applicable features ===

Depending on the variance of the generic, the applicable features differ:

* On a novariant generic, all features can be used.
* On a covariant generic, only features which have the formal generic as a result type can be used. If the formal generic appears in an argument this feature is invalid.
* On a contravariant generic, only feature which have the formal generc as an argument type can be used. If the formal generic appears as a result type this feature is invalid.

== Examples ==

See the [[introduction to examples]] for information about the classes used.

=== A simple generic algorithm ===

It is easy to declare an algorithm over generics as long as only read-access is needed. Just declare input to the algorithm as covariant list.

<e>
class PERSON_PRINTER
feature
print_all (a_list: LIST [+PERSON])
-- Print all attributes of each person in the list.
do
from
a_list.start
until
a_list.after
do
-- Reading is valid on a covariant list
a_list.item.print
end
end
end

class EXAMPLE
feature
make
local
l_students: LIST [STUDENT]
l_professors: LIST [PROFESSOR]
l_person_printer: PERSON_PRINTER
do
create l_person_printer
-- LIST [STUDENT] conforms to LIST [+PERSON]
l_person_printer.print_all (l_students)
-- LIST [PROFESSPR] conforms to LIST [+PERSON]
l_person_printer.print_all (l_professor)
end
end
</e>

=== Comparator ===

In the example of sorting a list with a comparator, contravariant generics can be used. Due to the use of <e>COMPARATOR [-G]</e> when sorting a <e>LIST [G]</e>, we allow to use a comparator which can sort more generally than just objects of type <e>G</e>. This allows to use a comparator for <e>ANY</e> objects to sort a list of strings.

<e>
class SORTER [G]
feature
sort (a_list: LIST [G]; a_comparator: COMPARATOR [-G])
do
-- Somewhere in the loop:
a_comparator.compare (l_string_1, l_string_2)
end
end

class EXAMPLE
feature
make
local
l_list: LIST [STRING]
l_string_sorter: SORTER [STRING]
l_string_comparator: COMPARATOR [STRING]
l_any_comparator: COMPARATOR [ANY]
do
-- COMPARATOR [STRING] conforms to COMPARATOR [-STRING]
l_string_sorter.sort (l_list, l_string_comparator)
-- COMPARATOR [ANY] conforms to COMPARATOR [-STRING]
l_string_sorter.sort (l_list, l_any_comparator)
end
end
</e>

=== Agents ===

For agents, we will look at an example with the type <e>T</e> and a subtype <e>U</e>. We will see an agent declaration and then check which arguments that are allowed:

==== Calling agents ====

<e>
local
an_agent: PROCEDURE [+ANY, -TUPLE [+T]]
-- An agent which takes an argument of type T.
do
-- The following calls are surely permitted (and also correct) since
-- the tuple generic inside the tuple is covariant and thus allows
-- the tuple of type U to be passed.
an_agent.call ([T])
an_agent.call ([U])

-- Due to the tuple conformance, the following calls are also
-- permitted. Note that they are both correct.
an_agent.call ([T, ...])
an_agent.call ([U, ...])
end
</e>

We see that this solution allows the full range of applicable arguments for calling agents.

==== Assigning agents ====

<e>
local
an_agent: PROCEDURE [+ANY, -TUPLE [+T]]
-- An agent which takes an argument of type T.
do
agent_empty := agent () do end --> PROCEDURE [ANY, TUPLE []]
agent_any := agent (a: ANY) do end --> PROCEDURE [ANY, TUPLE [+ANY]]
agent_t := agent (t: T) do end --> PROCEDURE [ANY, TUPLE [+T]]
agent_u := agent (u: U) do end --> PROCEDURE [ANY, TUPLE [+U]]
agent_tt := agent (t: T; t2: T) do end --> PROCEDURE [ANY, TUPLE [+T, +T]]

-- This assignment is naturally allowed.
an_agent := agent_t

-- This assignment is allowed since the tuple is declared contravariant
-- and the empty tuple is an ancestor of TUPLE [+T]
an_agent := agent_empty

-- This assignment is allowed and correct. The reason is that TUPLE [+ANY]
-- is an ancestor of TUPLE [+T].
an_agent := agent_any

-- The following assignments are not permitted by the solution. This is the correct
-- behaviour as you could either create a catcall by passing a T argument to the
-- `agent_u' or pass the wrong number of arguments by passing a [T] tuple to the
-- `agent_tt'.
an_agent := agent_u
an_agent := agent_tt
end
</e>

We see that this solution allows all possible agents to be assigned.

Since declaring an agent can be difficult (where did I need to put the "+" and the "-"?), an alternate [[Agent syntax|syntax for agents]] could be useful where the compiler can derive the correct type for an agent.

==== Vision 2 Example ====
A field which makes heavy use of agents and benefits a lot of them is event driven programming. With the current agent mechanism the programmer is sometimes forced to use a hack to circumvent the type checker in order to gain flexibility.

The following code is taken from <e>EV_PND_MOTION_ACTION_SEQUENCE</e>. Here we gain the flexibility that an agent which listens to the event does not have to be a feature which takes all the data provided if the event occurs.
<e>

force_extend (action: PROCEDURE [ANY, TUPLE]) is
-- Extend without type checking.
do
extend (agent wrapper (?, ?, ?, action))
end

wrapper (an_x, a_y: INTEGER; a_pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE; action: PROCEDURE [ANY, TUPLE]) is
-- Use this to circumvent tuple type checking. (at your own risk!)
-- Calls `action' passing all other arguments.
do
action.call ([an_x, a_y, a_pick_and_dropable])
end
</e>

If this solution is built into Eiffel the designer of Vision2 would do a small change in <e>ACTION_SEQUENCE</e>. The changes makes sure that we can accept agents to features defined in ancestors of <e>ANY</e> (therefore the <e>+ANY</e>) and that we accept agents which are not interested in all data but just (possibly) take parts of it (therefore -EVENT_DATA).
<e>
class
ACTION_SEQUENCE [EVENT_DATA -> +TUPLE create default_create end]
-- Note `+' in front of `TUPLE' as it is covariant, we accept all kind of EVENT_DATA
-- which is some subtype of `TUPLE'.

inherit
-- old ARRAYED_LIST [PROCEDURE [ANY, EVENT_DATA]]
ARRAYED_LIST [PROCEDURE [+ANY, -EVENT_DATA]]
rename
make as arrayed_list_make
export
{ACTION_SEQUENCE} same_items, subarray
redefine
default_create,
set_count
end
</e>

The wrapper code can be removed from <e>EV_PND_MOTION_ACTION_SEQUENCE</e> and we also change one line. This change empowers the system to accept descendants of <e>EV_ABSTRACT_PICK_AND_DROPABLE</e> as event data. The two integers do not need be marked covariantly as they are frozen and no descendants exist for them.
<e>
class
EV_PND_MOTION_ACTION_SEQUENCE

inherit
-- old EV_ACTION_SEQUENCE [TUPLE [x: INTEGER; y: INTEGER; pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE]]
EV_ACTION_SEQUENCE [TUPLE [x: INTEGER; y: INTEGER; pick_and_dropable: +EV_ABSTRACT_PICK_AND_DROPABLE]]
...
end
</e>
Now with this the actual signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.extend</e> looks like this:
<e>
extend (v: PROCEDURE [ANY, -TUPLE [x: INTEGER_32; y: INTEGER_32; +pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE]]
</e>

For the sake of completeness the signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.call</e>. Note again that the the field `pick_and_dropable' is covariant allowing to call the event with tuples containing descendants of <e>EV_ABSTRACT_PICK_AND_DROPABLE</e>.
<e>
call (event_data: TUPLE [x: INTEGER_32; y: INTEGER_32; pick_and_dropable: +EV_ABSTRACT_PICK_AND_DROPABLE])
</e>

== Conclusion ==

The usage-site variance is a mechanism which allows both expressive and type-safe generics. It can model agents and comparator types correctly.

Usage-site variance

2007-06-23T22:35:12Z

Seilerm: /* Vision 2 Example */

[[Category:ECMA]]
[[Category:Catcall]]
== Introduction ==

The usage-site variance allows the programmer to choose which kind of variance he wants to use when a generic derivation is declared. This allows to use every generic as novariant, covariant or contravariant in contrast to the [[definition-site variance]] where it is set in the class definition.

== Syntax ==

The syntax used here to specify the variance of a generic is simple and may be changed to something more verbose but also clearer:

* To specify a novariant generic, the normal syntax can be used: <e>LIST [ANY]</e>
* To specify a covariant generic, we use a plus sign: <e>LIST [+ANY]</e>
* To specify a contravariant generic, we use a minus sign: <e>LIST [-ANY]</e>

== Semantics ==

See the [[introduction to examples]] for information about the classes used.

=== Conformance rules ===

Depending on the variance of the generic, the conformance rules differ:

* A generic conforms to a novariant generic if it has the exact same generic parameter. Thus <e>LIST [T]</e> only conforms to <e>LIST [T]</e>. Note that <e>LINKED_LIST [T]</e> also conforms to <e>LIST [T]</e> as long as the generic parameter matches.
* A generic conforms to a covariant generic if its generic parameter conforms to the generic parameter of the covariant generic. Thus <e>LIST [U]</e> conforms to <e>LIST [+T]</e>.
* A generic conforms to a contravariant generic if its generic parameter is a parent of the generic parameter of the contravariant generic. Thus <e>LIST [T]</e> conforms to <e>LIST [-U]</e>.

For the conformance of tuples, we keep that a tuple with more elements conforms to a tuple with less elements as long as the common elements conform:

* <e>TUPLE [T, U]</e> conforms to <e>TUPLE [T]</e>
* <e>TUPLE [U, U]</e> conforms to <e>TUPLE [+T]</e>
* <e>TUPLE [T, U]</e> conforms to <e>TUPLE [-U]</e>

=== Applicable features ===

Depending on the variance of the generic, the applicable features differ:

* On a novariant generic, all features can be used.
* On a covariant generic, only features which have the formal generic as a result type can be used. If the formal generic appears in an argument this feature is invalid.
* On a contravariant generic, only feature which have the formal generc as an argument type can be used. If the formal generic appears as a result type this feature is invalid.

== Examples ==

See the [[introduction to examples]] for information about the classes used.

=== A simple generic algorithm ===

It is easy to declare an algorithm over generics as long as only read-access is needed. Just declare input to the algorithm as covariant list.

<e>
class PERSON_PRINTER
feature
print_all (a_list: LIST [+PERSON])
-- Print all attributes of each person in the list.
do
from
a_list.start
until
a_list.after
do
-- Reading is valid on a covariant list
a_list.item.print
end
end
end

class EXAMPLE
feature
make
local
l_students: LIST [STUDENT]
l_professors: LIST [PROFESSOR]
l_person_printer: PERSON_PRINTER
do
create l_person_printer
-- LIST [STUDENT] conforms to LIST [+PERSON]
l_person_printer.print_all (l_students)
-- LIST [PROFESSPR] conforms to LIST [+PERSON]
l_person_printer.print_all (l_professor)
end
end
</e>

=== Comparator ===

In the example of sorting a list with a comparator, contravariant generics can be used. Due to the use of <e>COMPARATOR [-G]</e> when sorting a <e>LIST [G]</e>, we allow to use a comparator which can sort more generally than just objects of type <e>G</e>. This allows to use a comparator for <e>ANY</e> objects to sort a list of strings.

<e>
class SORTER [G]
feature
sort (a_list: LIST [G]; a_comparator: COMPARATOR [-G])
do
-- Somewhere in the loop:
a_comparator.compare (l_string_1, l_string_2)
end
end

class EXAMPLE
feature
make
local
l_list: LIST [STRING]
l_string_sorter: SORTER [STRING]
l_string_comparator: COMPARATOR [STRING]
l_any_comparator: COMPARATOR [ANY]
do
-- COMPARATOR [STRING] conforms to COMPARATOR [-STRING]
l_string_sorter.sort (l_list, l_string_comparator)
-- COMPARATOR [ANY] conforms to COMPARATOR [-STRING]
l_string_sorter.sort (l_list, l_any_comparator)
end
end
</e>

=== Agents ===

For agents, we will look at an example with the type <e>T</e> and a subtype <e>U</e>. We will see an agent declaration and then check which arguments that are allowed:

==== Calling agents ====

<e>
local
an_agent: PROCEDURE [+ANY, -TUPLE [+T]]
-- An agent which takes an argument of type T.
do
-- The following calls are surely permitted (and also correct) since
-- the tuple generic inside the tuple is covariant and thus allows
-- the tuple of type U to be passed.
an_agent.call ([T])
an_agent.call ([U])

-- Due to the tuple conformance, the following calls are also
-- permitted. Note that they are both correct.
an_agent.call ([T, ...])
an_agent.call ([U, ...])
end
</e>

We see that this solution allows the full range of applicable arguments for calling agents.

==== Assigning agents ====

<e>
local
an_agent: PROCEDURE [+ANY, -TUPLE [+T]]
-- An agent which takes an argument of type T.
do
agent_empty := agent () do end --> PROCEDURE [ANY, TUPLE []]
agent_any := agent (a: ANY) do end --> PROCEDURE [ANY, TUPLE [+ANY]]
agent_t := agent (t: T) do end --> PROCEDURE [ANY, TUPLE [+T]]
agent_u := agent (u: U) do end --> PROCEDURE [ANY, TUPLE [+U]]
agent_tt := agent (t: T; t2: T) do end --> PROCEDURE [ANY, TUPLE [+T, +T]]

-- This assignment is naturally allowed.
an_agent := agent_t

-- This assignment is allowed since the tuple is declared contravariant
-- and the empty tuple is an ancestor of TUPLE [+T]
an_agent := agent_empty

-- This assignment is allowed and correct. The reason is that TUPLE [+ANY]
-- is an ancestor of TUPLE [+T].
an_agent := agent_any

-- The following assignments are not permitted by the solution. This is the correct
-- behaviour as you could either create a catcall by passing a T argument to the
-- `agent_u' or pass the wrong number of arguments by passing a [T] tuple to the
-- `agent_tt'.
an_agent := agent_u
an_agent := agent_tt
end
</e>

We see that this solution allows all possible agents to be assigned.

Since declaring an agent can be difficult (where did I need to put the "+" and the "-"?), an alternate [[Agent syntax|syntax for agents]] could be useful where the compiler can derive the correct type for an agent.

==== Vision 2 Example ====
A field which makes heavy use of agents and benefits a lot of them is event driven programming. With the current agent mechanism the programmer is sometimes forced to use a hack to circumvent the type checker in order to gain flexibility.

The following code is taken from <e>EV_PND_MOTION_ACTION_SEQUENCE</e>. Here we gain the flexibility that an agent which listens to the event does not have to be a feature which takes all the data provided if the event occurs.
<e>

force_extend (action: PROCEDURE [ANY, TUPLE]) is
-- Extend without type checking.
do
extend (agent wrapper (?, ?, ?, action))
end

wrapper (an_x, a_y: INTEGER; a_pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE; action: PROCEDURE [ANY, TUPLE]) is
-- Use this to circumvent tuple type checking. (at your own risk!)
-- Calls `action' passing all other arguments.
do
action.call ([an_x, a_y, a_pick_and_dropable])
end
</e>

If this solution is built into Eiffel the designer of Vision2 would do a small change in <e>ACTION_SEQUENCE</e>. The changes makes sure that we can accept agents to features defined in ancestors of <e>ANY</e>, therefore the <e>+ANY</e> and that we accept agents which are not interested in all data but just (possibly) take parts of it.
<e>
class
ACTION_SEQUENCE [EVENT_DATA -> +TUPLE create default_create end]

inherit
-- old ARRAYED_LIST [PROCEDURE [ANY, EVENT_DATA]]
ARRAYED_LIST [PROCEDURE [+ANY, -EVENT_DATA]]
rename
make as arrayed_list_make
export
{ACTION_SEQUENCE} same_items, subarray
redefine
default_create,
set_count
end
</e>

The wrapper code can be removed from <e>EV_PND_MOTION_ACTION_SEQUENCE</e> and we also change one line. This change empowers the system to accept descendants of <e>EV_ABSTRACT_PICK_AND_DROPABLE</e> as event data. The two integers do not need be marked covariantly as they are frozen and no descendants exist for them.
<e>
class
EV_PND_MOTION_ACTION_SEQUENCE

inherit
-- old EV_ACTION_SEQUENCE [TUPLE [x: INTEGER; y: INTEGER; pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE]]
EV_ACTION_SEQUENCE [TUPLE [x: INTEGER; y: INTEGER; pick_and_dropable: +EV_ABSTRACT_PICK_AND_DROPABLE]]
...
end
</e>
Now with this the actual signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.extend</e> looks like this:
<e>
extend (v: PROCEDURE [ANY, -TUPLE [x: INTEGER_32; y: INTEGER_32; +pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE]]
</e>

For the sake of completeness the signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.call</e>. Note again that the the field `pick_and_dropable' is covariant allowing to call the event with tuples containing descendants of <e>EV_ABSTRACT_PICK_AND_DROPABLE</e>.
<e>
call (event_data: TUPLE [x: INTEGER_32; y: INTEGER_32; pick_and_dropable: +EV_ABSTRACT_PICK_AND_DROPABLE])
</e>

== Conclusion ==

The usage-site variance is a mechanism which allows both expressive and type-safe generics. It can model agents and comparator types correctly.

Usage-site variance

2007-06-23T21:24:06Z

Seilerm: /* Agents */

Forget / keep

2007-06-23T19:09:40Z

Seilerm: /* A Simple Generic Algorithm */

[[Category:ECMA]]
[[Category:Catcall]]
== Introduction ==

The forget / keep mechanism enhances the type system. It allows to change types on the feature level by ''forgetting'' specific features (especially features which are covariantly redefined) so that these features can't be called anymore. It also allows to specifically ''keep'' certain features so that they are surely available which in turn changes the conformance rules to only allow types which have this feature with the exact same signature.

== Syntax ==

<e>
-- forget types

-- A type which forgets all covariantly redefined features, thus all
-- subtypes conform to this type.
a: ANIMAL forget all end

-- A type which only forgets the features `eat' and `sleep' but not other
-- covarianlty redefined features or features whose export status is
-- restricted. All subtypes which only redefine or restrict export status
-- of `eat' or `sleep' will conform to this type.
a: ANIMAL forget eat, sleep end

-- keep types

-- A type which keeps all features and looses conformance from subtypes which
-- covariantly redefine features or restrict export status.
b: ANIMAL keep all end

-- A type where all subtypes conform except those who covariantly redefine
-- feature `eat'.
b: ANIMAL keep eat end
</e>

== Semantics ==

The meaning of a ''forget'' clause is that the actual type which is used does not have the features listed in the forget clause. <e>forget all</e> is a bit misleading as it does not forget all features, but only features which are covariantly redefined or have the export status changed to be more restrictive later in the inheritance hierarchy. A better naming would be something along the lines of <e>forget covariance</e> but this does not address the export status change.

The meaning of a ''keep'' clause is the reverse. If a feature is listed in a ''keep'' clause it can be called on that type with the arguments listed in that type. This means in turn that all subclasses which change the signature of those features covariantly don't conform anymore as a call would not be safe anymore.

=== Default behavior ===

The mechanism has two possible default behaviors. If a type is declared without specifying which features to keep or to forget, it can either mean a type which keeps all features or a type which forgets all features. The default behavior has a big impact on the language:
* In the ''keep all'' case, all subclasses which have a covariantly redefined feature don't conform to the parent type anymore as it ''keeps'' this feature.
* In the ''forget all'' case, all subclasses conform to the parent per default, but all features which are covariantly redefined (even much later in the inheritance hierarchy) are not callable since they are ''forgotten''.

=== Conformance rules ===

Conformance is best explained on the feature level. A type <e>SUB</e> conforms to a type <e>PARENT</e> if all features which are available in <e>PARENT</e> are also available in <e>SUB</e>. You have to keep in mind that the type <e>PARENT</e> can forget certain features. Thus <e>SUB</e> only conforms to the type <e>PARENT forget x</e> if SUB also has a <e>forget x</e> clause. For the keep clause it is a little bit different: A type <e>SUB</e> only conforms to the type <e>PARENT keep x</e> if <e>SUB</e> does not restrict the export status of <e>x</e> or changes the arguments covariantly, thus it has the same interface regarding feature <e>x</e>.

== Examples ==

See the [[introduction to examples]] for information about the classes used.

=== Cats and Dogs ===

The examples are taken from the [http://dev.eiffel.com/Forget_/_Keep_Mechanism#Covariant_feature_redefinition reference article]

==== forget mechanism ====

The example regarding covariance on the feature level with the forget mechanism looks as follows:

<e>
local
a: ANIMAL -- means ANIMAL keep all
c: CAT
do
-- illegal assignment, ANIMAL and CAT don't conform
-- since CAT does not have the same signature for `eat'
a := c
a.eat (food)
end
</e>

<e>
local
a: ANIMAL forget all end
c: CAT
do
-- legal, CAT conforms to ANIMAL forget all
a := c

-- illegal, ANIMAL forget all doesn't have a feature eat
a.eat (food)
end
</e>

==== keep mechanism ====

The example regarding covariance on the feature level with the keep mechanism looks as follows:

<e>
local
a: ANIMAL -- means ANIMAL forget all
c: CAT
do
a := c
-- illegal call since the type ANIMAL does not have a feature `eat' anymore
a.eat (food)
end
</e>

<e>
local
a: ANIMAL keep all end
c: CAT
do
-- illegal, CAT does not conform to ANIMAL keep all
a := c

-- legal, ANIMAL keep all still has the feature `eat'
a.eat (food)
end
</e>

=== A Simple Generic Algorithm ===

<e>
deferred class PERSON_PRINTER
feature

print_attributes (a_list: LIST [PERSON] forget all)
-- Print all attributes of each person in the list.
deferred
end
end

deferred class EXAMPLE
feature
example
-- Shows example usage of PERSON_PRINTER.
local
l_students: LINKED_LIST [STUDENT]
l_professors: LINKED_LIST [PROFESSOR]
l_person_printer: PERSON_PRINTER
do
create l_person_printer
l_person_printer.print_attributes (l_students)
l_person_printer.print_attributes (l_professor)
end
end
</e>

By forgetting all covariantly redefined features the generics conform and we can reuse this algorithm for all implementations of <e>LIST</e> of descendants of <e>PERSON</e>.

== Conclusion ==
This proposal solves CAT calls as a whole. This include CAT calls which are introduced by covariant argument redefinition through formal arguments in generic classes.
It is not as expressive as other solutions (not applicable to agents, comparator example) and it is likely that it adds a lot of syntax to the code.

Comparison of catcall solutions

2007-06-23T02:28:59Z

Seilerm: /* Generic vs. non-generic covariance */

[[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 statically 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?
; 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?
; 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, ISE 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.

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

{| border=1 cellpadding=2

|- style="visibility: hidden"
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |

|-

|colspan=4 |
=== General solutions ===

|-

! Criteria
! [[Novariance]]
! [[Forget / keep]]
! Dynamic typeset algorithm

|-

! Syntax overhead
| {{Green|No}}
| {{Red|Big}}: forget/keep clauses per type
| {{Green|No}}

|-

! Covariance on non-generic types
| {{Red|Not allowed}}
| {{Green|Allowed}}
| {{Green|Allowed}}

|-

! Export status restrictions
| {{Red|Not allowed}}
| {{Green|Allowed}}
| {{Green|Allowed}}

|-

! Use of generic types
| {{Red|Very limited}}: Only invariant conformance
| {{Orange|Limited}}
| {{Green|As it is now}}

|-

! Agents
| {{Orange|Limited}} {{Green|Safe}}
| {{Red|Very limited}}
| {{Red|As it is now}}

|-

! Comparator
| {{Red|Not supported}}
| {{Red|Not supported}}
| {{Red|Not supported}}

|-

! Whole-system analysis
| {{Green|No}}
| {{Orange|Partial}}
| {{Red|Yes}}

|-

! Dynamic class and type loading
| {{Green|Yes}}
| {{Orange|Limited}}
| {{Red|No}}

|-

! Backward compatibility
| {{Red|Very limited}}
| {{Orange|Limited}}
| {{Green|Full}}

|-

! Support of IDE (Source changes)
| {{Green|Not needed}}
| {{Red|Difficult}}
| {{Green|Not needed}}

|-

|colspan=4 |

=== Solutions for non-generics ===

|-

! 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

|-

! 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

|-

|colspan=4 |

=== Solutions for generics ===

|-

! 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|Save}}
| {{Orange|Almost fully supported}} {{Green|Save}}
| {{Green|Fully supported}} {{Green|Save}}

|-

! Comparator
| {{Green|Supported}}
| {{Green|Supported}}
| {{Green|Supported}}

|-

! 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

|-

|colspan=4 |

=== Dynamic solutions ===

|-

! 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|As it is now}}
| {{Green|As it is now}}
|-

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

|-

! 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

|}

== Personal opinions ==

[[Personal view about catcall solution]]

Comparison of catcall solutions

2007-06-23T02:28:21Z

Seilerm: /* Generic vs. non-generic covariance */

[[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 statically 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?
; 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?
; 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, ISE 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 LIST [ANY] to LINKED_LIST [ANY] 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.

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

{| border=1 cellpadding=2

|- style="visibility: hidden"
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |
| style="width:25%" |

|-

|colspan=4 |
=== General solutions ===

|-

! Criteria
! [[Novariance]]
! [[Forget / keep]]
! Dynamic typeset algorithm

|-

! Syntax overhead
| {{Green|No}}
| {{Red|Big}}: forget/keep clauses per type
| {{Green|No}}

|-

! Covariance on non-generic types
| {{Red|Not allowed}}
| {{Green|Allowed}}
| {{Green|Allowed}}

|-

! Export status restrictions
| {{Red|Not allowed}}
| {{Green|Allowed}}
| {{Green|Allowed}}

|-

! Use of generic types
| {{Red|Very limited}}: Only invariant conformance
| {{Orange|Limited}}
| {{Green|As it is now}}

|-

! Agents
| {{Orange|Limited}} {{Green|Safe}}
| {{Red|Very limited}}
| {{Red|As it is now}}

|-

! Comparator
| {{Red|Not supported}}
| {{Red|Not supported}}
| {{Red|Not supported}}

|-

! Whole-system analysis
| {{Green|No}}
| {{Orange|Partial}}
| {{Red|Yes}}

|-

! Dynamic class and type loading
| {{Green|Yes}}
| {{Orange|Limited}}
| {{Red|No}}

|-

! Backward compatibility
| {{Red|Very limited}}
| {{Orange|Limited}}
| {{Green|Full}}

|-

! Support of IDE (Source changes)
| {{Green|Not needed}}
| {{Red|Difficult}}
| {{Green|Not needed}}

|-

|colspan=4 |

=== Solutions for non-generics ===

|-

! 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

|-

! 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

|-

|colspan=4 |

=== Solutions for generics ===

|-

! 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|Save}}
| {{Orange|Almost fully supported}} {{Green|Save}}
| {{Green|Fully supported}} {{Green|Save}}

|-

! Comparator
| {{Green|Supported}}
| {{Green|Supported}}
| {{Green|Supported}}

|-

! 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

|-

|colspan=4 |

=== Dynamic solutions ===

|-

! 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|As it is now}}
| {{Green|As it is now}}
|-

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

|-

! 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

|}

== Personal opinions ==

[[Personal view about catcall solution]]

Agent syntax

2007-06-23T01:56:17Z

Seilerm: initial copy from internal wiki

[[Category:ECMA]]
==Agent syntax==

Idea: Use the '''like''' keyword followed by an agent signature definition to define agent types.

The good thing is that in Eiffel the "like" mechanism is already in place and well understood. In order to define an agent type something like
<e>
an_agent: like agent (a_x, a_y: INTEGER): BOOLEAN
</e>
would be very handy. Note that it is very similar to the definition of an inline agent. Of course the argument names could be omitted. But by allowing it we can even provide a named tuple as the argument signature for the call feature.
<e>
an_agent: like agent (INTEGER; INTEGER): BOOLEAN
</e>

The reason to introduce a syntax like this is to let the compiler handle the correct type of the agent. Depending if the type system is enhanced on a per-declaration syntax - like the [[restrict types]] or the [[usage-site variance]] propose - then the definition of an agent can be very cumbersome. By giving the programmer a shorthand he does not need to specify the exact agent type himself.

Definition-site variance

2007-06-23T01:55:09Z

Seilerm:

[[Category:ECMA]]
[[Category:Catcall]]
== Introduction ==

The defintion-site variance allows the programmer to choose which kind of variance he wants to use in the defintion of a generic class. Unlike the [[usage-site variance]], this fixes a specific class to the kind of variance which it supports.

== Syntax ==

The syntax used here to specify the variance of a generic is simple and may be changed to something more verbose but also clearer:

* To specify a novariant generic, the normal syntax can be used: <e>class LIST [G] end</e>
* To specify a covariant generic, we use a plus sign: <e>class READ_LIST [+G] end</e>
* To specify a contravariant generic, we use a minus sign: <e>class WRITE_LIST [-G] end</e>

== Semantics ==

See the [[introduction to examples]] for information about the classes used.

=== Conformance rules ===

Depending on the variance of the generic, the conformance rules differ:

* If a generic class is declared novariant, two generics conform if their base class conforms and the generic parameters match exactly. Thus <e>LIST [T]</e> only conforms to <e>LIST [T]</e>.
* If a generic class is declared covariant, a generic conforms to another if its base class conforms and the generic parameter conforms to the other. Thus <e>READ_LIST [U]</e> conforms to <e>READ_LIST [T]</e>.
* If a generic class is declared contravariant, a generic conforms to another if its base class conforms and the generic parameter is an ancestor of the other. Thus <e>WRITE_LIST [U]</e> conforms to <e>WRITE_LIST [T]</e>.

Tuples are problematic in this solution as have to declare the generic tuple parameters as invariant. For the conformance of tuples, we keep that a tuple with more elements conforms to a tuple with less elements. The common elements have to match exactly due to their invariance:

* <e>TUPLE [T, U]</e> conforms to <e>TUPLE [T]</e>
* <e>TUPLE [U]</e> does not conform to <e>TUPLE [T]</e>

=== Applicable features ===

Depending on the variance of a generic, it can only occur in certain places:

* A novariant generic can be used as argument or result type.
* A covariant generic can only be used as a result type.
* A contravariant generic can only be used as an argument type.

== Examples ==

See the [[introduction to examples]] for information about the classes used.

=== A simple generic algorithm ===

In order to use lists as read-only lists, the library design has to be adapted. <e>LIST [G]</e> needs to inherit from <e>READ_LIST [+G]</e>. That way you can assign a <e>LIST [STRING]</e> to a <e>READ_LIST [STRING]</e> and, through transitivity of conformance, to a <e>READ_LIST [ANY]</e>.

<e>
class PERSON_PRINTER
feature
print_all (a_list: READ_LIST [PERSON])
-- Print all attributes of each person in the list.
do
from
a_list.start
until
a_list.after
do
-- Reading is valid on a covariant list
a_list.item.print
end
end
end

class EXAMPLE
feature
make
local
l_students: LIST [STUDENT]
l_professors: LIST [PROFESSOR]
l_person_printer: PERSON_PRINTER
do
create l_person_printer
-- LIST [STUDENT] conforms to READ_LIST [PERSON]
l_person_printer.print_all (l_students)
-- LIST [PROFESSOR] conforms to READ_LIST [PERSON]
l_person_printer.print_all (l_professor)
end
end
</e>

=== Comparator ===

For the comparator example to work, the comparator class has to be declared as contravariant generic: <e>class COMPARATOR [-G]</e>.

<e>
class SORTER [G]
feature
sort (a_list: LIST [G]; a_comparator: COMPARATOR [G])
do
-- Somewhere in the loop:
a_comparator.compare (l_string_1, l_string_2)
end
end

class EXAMPLE
feature
make
local
l_list: LIST [STRING]
l_string_sorter: SORTER [STRING]
l_string_comparator: COMPARATOR [STRING]
l_any_comparator: COMPARATOR [ANY]
do
-- COMPARATOR [STRING] conforms to COMPARATOR [STRING]
l_string_sorter.sort (l_list, l_string_comparator)
-- COMPARATOR [ANY] conforms to COMPARATOR [STRING]
l_string_sorter.sort (l_list, l_any_comparator)
end
end
</e>

=== Agents ===

Again, to use definition-site variance you have to adapt the library design. The procedure class has to be defined as follows:

<e>
class PROCEDURE [+BASE_TYPE, -OPEN_ARGS -> TUPLE]
end
</e>

==== Calling agents ====

<e>
local
an_agent: PROCEDURE [ANY, TUPLE [T]]
-- An agent which takes an argument of type T.
do
-- The following calls are surely permitted as the generic
-- parameter in the tuple is novariant since it is not specified
-- further in the procedure class.
an_agent.call ([T])
an_agent.call ([T, ...])

-- Because the tuple is novariant, the following calls are
-- illegal although they would be safe.
an_agent.call ([U])
an_agent.call ([U, ...])
end
</e>

In contrast to [[usage-site variance#Agents|usage-site variance]] you cannot express that the generic parameters of the tuple are covariant. Because of that, the call with a subtype of the actual parameter is not permitted by the type system.

==== Assigning agents ====

<e>
local
an_agent: PROCEDURE [ANY, TUPLE [T]]
-- An agent which takes an argument of type T.
do
agent_empty := agent () do end --> PROCEDURE [ANY, TUPLE []]
agent_any := agent (a: ANY) do end --> PROCEDURE [ANY, TUPLE [ANY]]
agent_t := agent (t: T) do end --> PROCEDURE [ANY, TUPLE [T]]
agent_u := agent (u: U) do end --> PROCEDURE [ANY, TUPLE [U]]
agent_tt := agent (t: T; t2: T) do end --> PROCEDURE [ANY, TUPLE [T, T]]

-- This assignment is naturally allowed.
an_agent := agent_t

-- This assignment is allowed since the tuple is declared contravariant
-- and the empty tuple is an ancestor of TUPLE [T]
an_agent := agent_empty

-- This assignment is not allowed although it would be correct. The reason
-- is that TUPLE [ANY] is not an ancestor of TUPEL [T].
an_agent := agent_any

-- The following assignments are not permitted by the solution. This is the correct
-- behaviour as you could either create a catcall by passing a T argument to the
-- `agent_u' or pass the wrong number of arguments by passing a [T] tuple to the
-- `agent_tt'.
an_agent := agent_u
an_agent := agent_tt
end
</e>

Again, the fact that the generic tuple parameters are novariant causes that a safe assignment is prohibited.

== Conclusion ==

This solution requires that the libraries are designed in a way which separates reading and writing to generic datastructes. It allows full use of comparator objects but does not fully support agents.

On the plus side, the client of a library does not need to put variance markers as in the [[usage-site variance]] proposal which makes the use of the solution easier for the normal programmer.

Detachable types

2007-06-23T01:54:00Z

Seilerm: copy from internal wiki

[[Category:ECMA]]
[[Category:Catcall]]
== Introduction ==

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.

This is specified in the [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA Eiffel standard 2nd edition of June 2006].

== Syntax ==

No new syntax is necessary.

== Semantics ==

In this solution, it is only allowed to covariantly redefine arguments to detachable types. This ensures that an object test is done before the use of an argument. If now a catcall happens, the object test will fail. Since the argument is of detachable type, the programmer has to handle the case where Void is passed anyway and this also handles the catcall.

== Examples ==

=== Cats and dogs ===

The definition of the CAT class changes as follows:
<e>
class CAT
inherit ANIMAL redefine eat end
feature
eat (food: ? CAT_FOOD)
do
if {cat_food: CAT_FOOD} food then
-- Use `cat_food'
else
-- either Void or an argument of type FOOD passed
end
end
end
</e>

== Issues ==

=== Weak covariance support ===

See [http://dev.eiffel.com/New_CAT_call article on dev.eiffel.com].

=== Generics ===

With the current conformance of generics, different generic derivations can be seen as if they covariantly redefined the features with formal generic parameters. For example feature <e>put</e> from the class <e>LIST</e> if you look at the signature of <e>LIST [ANY]</e> compared to <e>LIST [STRING]</e>. As with anchored types as parameters, you would also have to specify that all formal generic parameters need to be detached. This would mean that all classes which use generic parameters always have to use object tests to use the generic parameters, and Void-safety cannot be expressed on the type system level which would remove the main benefit of attached types in the context of generics.

=== Expanded types ===

The type rule specified by ECMA (VTCT, 8.11.8) defines that an expaned type cannot have an attachment mark since Void is not a valid value for it. Given that covariant feature redeclaration, especially anchored types for arguments, can only occur with detached types, this means that arguments cannot be covariantly redefined into expaned types.

The base classes like <e>INTEGER</e> which currently inherit from <e>NUMERIC</e> which only defines it's arguments as <e>like Current</e> would be invalid in their current form. Also if formal generic parameters need to be detached as explained above, generic derivations would not be allowed for expaned types if the formal generic occurs as a parameter of a feature. Especially <e>LIST [INTEGER]</e> would not be possible.

== Conclusion ==

The problems arise partially due to the fact that two concepts are mixed:
* Attachable/detachable types: A type <e>? T</e> can be attached to an object of type T or not attached at all (i.e. Void)
* Catcall arguments: In a catcall, the type of the argument can either be the expected type or the type of an ancestor version of the feature.

By using detachable types to solve catcalls, the notion of a detachable type is expaned to be able to hold types of all ancestors as well.

In addition to this, the problems with generics and expanded types show that this solution does severly limit the usefulness of covariance.

EiffelStudio 6.0 Features

2007-04-24T17:41:11Z

Seilerm: /* Eiffel Language/Compiler */

[[Category:Releases]]

This page highlights some of the major feature changes between versions 5.7 and the forthcoming 6.0 release of EiffelStudio.

For the 6.0 change log see [[EiffelStudio Releases]].

== EiffelStudio (General) ==

* New docking manager graphical interface

== New Tools ==

== Debugger ==

== Eiffel Language/Compiler ==

* [[Compilation Without Configuration]]
* Multi constraint formal generic type parameters

== Libraries ==

Current implementation of multi constraint formals

2007-04-24T17:39:22Z

Seilerm: /* Creation without call to explicit creation feature */

[[Category:Compiler]]
{{UnderConstruction}}

==Introduction==
The first implementation of multi constraints is done and this article describes its current implementation status.

Let's take this example
<e>
MULTI [G -> {H, COMPARABLE rename is_equal as is_equal_cmp end},
H -> {NUMERIC rename default_create as default_create_num end, G}]
</e>
A type satisfying the constraint of ''G'' has the following properties:
* It conforms to whatever ''H'' is and therefore
** to <e>NUMERIC</e> and
** by recursion to itself (''G'')
* It conforms to its second constraint which is <e>COMPARABLE</e>.

A type satisfying the constraint of ''H'' has the following properties:
* It conforms to <e>NUMERIC</e>.
* It conforms to ''G'' and therefore
** by recursion to itself (''H'') and
** to <e>COMPARABLE</e>.

As ''G'' and ''H'' both have to conform to each other the only possibility to satisfy this is that ''G'' and ''H'' must be the same in the generic derivation. It does not make much sense to program something like that but it is part of the current implementation.

=== Feature calls ===

Let's have a look at the following feature written in class ''MULTI'':
<e>
feature
g: G

f: BOOLEAN
-- Sample feature
do
create g -- 1
Result := g.is_equal(g) -- 2
end
</e>
The following rules have to hold for each call on a multi constraint formal:
* Every feature which is called has exactly one class which is used as the static type for the call.

This is a major difference to the ECMA standard which allows a call to features which are available through different classes as long as it is the same feature. A definition of what the ''same feature'' means can be found [[Replication|here]].

In order to achieve that goal if a feature occurs with the same name in different classes one uses a rename clause and renames that feature. If there are name clashes between features and one does not want to call that feature a renaming is '''not''' needed.

As we perform calls to <e>default_create</e> (line 1 of <e>f</e>) and <e>is_equal</e> (line 2 of <e>f</e>, which are both features from <e>ANY</e> and each occurs as the same feature once in <e>COMPARABLE</e> and once in <e>NUMERIC</e>. We do this despite the fact that it is actually the same feature. The reason for this can be found in the new semantics of the dynamic binding described in the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard]. You may also want to have a look at the following [[Multiple_constraints|article]] which discusses the issue.

=== Renaming on formals ===

The current implementation rejects a rename clause which is applied to a formal. The following code is therefore currently rejected as H is a formal and we don't allow a renaming on it.
<e>
class MULTI[G -> {H rename is_equal as is_equal_prime end, ANY}, H -> ANY]
</e>

The rules implemented are chosen so that they are the most restrictive. This is to ensure that written code is likely to compile in the future where the rules might be more relaxed.

=== Creation without call to explicit creation feature ===
{{Note|This is not implemented in interim release 6.0.6.7358 or older.}}
<e>
class MULTI [G -> {COMPARABLE rename default_craete as default_create2 end,
NUMERIC} create default_create, default_create2 end]
</e>

A creation like <e>create g</e> where ''g'' is of type ''G'' yields an error as
there are two versions of ''default_create'' available.

==Implementation details==

The current implementation is pretty straightforward and tries to be as non-intrusive as possible. Most things rely on computation rather than on memory. For example there's no list which contains all features properly renamed but only a relatively small instance of <e>RENAMING_A</e> which contains a mapping of the name-ids.

The central classes to the current implementation are:
* <e>TYPE_SET_A</e>
* <e>RENAMED_TYPE_A</e>
* <e>RENAMING_A</e>
* <e>CONSTRAINING_TYPE_AS</e>
* and some changes to <e>CLASS_C</e>

The main tasks which have to be performed are:
* Type checking in particular type conformance.
* Feature lookup

Both tasks are provided by <e>TYPE_SET_A</e>.
===TYPE_SET_A===
====Conformance====
The feature <e>conform_to</e> inherited from <e>TYPE_A</e> can be used to check whether a type set conforms to another type which is possibly a type set as well.

* A type set conforms to another type if at least one type in the type
set conforms to the type.
* Another type conforms to a type set if it conforms to all types in the type set.
* A type set ''ts1'' conforms to a type set ''ts2'' if for each type ''t'' in ''ts2'' there is at least one type in ''ts1'' which conforms to ''t''.

If every type is regarded as a type set with one element one can simply always use the last rule.

====Feature lookup====
There are various features which provide this functionality. Their differences are mostly in the amount of information they provide. Of course the computation gets more expensive if the feature returns more information.
Currently the API is pretty much targeted to what the compiler needs.
There's a bunch of features of the family ''e_feature_state_*''/''feature_i_state_*'' which are used when most likely only one feature occurs.
As soon as you need more information the features of the family ''info_about_feature_*'' can help you to get all information about a certain feature for a given type set.

Now there is one more thing to add: As a type set which you obtain over <e>{CLASS_C}.constraints (a_formal_position)</e> can contain formals, which themselves can have constraints and therefore add more available features, one needs to compute somehow a "flat" version of the type set. This version cannot be used anymore for meaning full type checking but is perfectly suited to do feature queries.
<e>
class MULTI [G -> {H, I}, H -> COMPARABLE, I -> NUMERIC]
</e>
Consider now the following code which works on the <e>CLASS_C</e> object of class <e>MULTI</e> called <e>multi_class</e>

<e>
a_type_set_with_formals := multi_class.constraints (1)
-- a_type_set_with_formals: {H, I}
a_type_set_without_formals := a_type_set_with_formals.constraining_types (multi_class)
-- a_type_set_without_formals: {COMPARABLE, NUMERIC}
</e>

It basically gets rid of all formals (even recursive cases are handled correctly) and puts together a new type set which can be used for example to show all classes which provide features to a formal or to do feature lookup. The fact that there's no good reason to use it for conformance suggests that one refactors this class into two classes: One for type checking and one for feature lookup.

====Associated class====
This feature is no longer available and therefore exported to NONE. This is simply because there is no single associated class but many.
You can use the feature ''associated_classes'' instead and get a list of all associated classes.
However, the features applicable to the type set is not the same set as the features provided by each element of the ''associated_classes''. This is because one loses the renaming (class <e>RENAMING_A</e>) which is stored inside the <e>TYPE_SET_A</e> in each <e>RENAMED_TYPE_A</e> instance. This is why there are some places in the code where going from a <e>CLASS_C</e> instance to one of type <e>LIST [CLASS_C]</e> is not enough.

===RENAMED_TYPE_A===
The <e>RENAMED_TYPE_A</e> class basically encapsulates a <e>TYPE_A</e> object and a <e>RENAMING_A</e> object.
The fact that it is conform to TYPE_A opens the door for mistakes: Make sure that you use <e>{RENAMED_TYPE_A}.type</e> or <e>{RENAMED_TYPE_A}.actual_type</e> if your code makes assignment attempts, it is pretty much the same as with the family of the "like" types.

===RENAMING_A===
This is the class which provides features to handle the renaming which is applied to the features of the constraint type.

It's current implementation is based on a hash table and therefore only one way is efficient.

You can find out whether a specific feature is renamed by calling <e>is_feature_renamed</e>. There's also a predefined feature <e>renamed</e> which takes an integer argument and returns another one. The integer returned is either
* unchanged, if the feature is not renamed
* some other positive integer if the feature is renamed under the renaming
* -1 if the feature was renamed into something else (therefore it is not accessible)

However, this is only relative to the renaming and is not in the context of a specific class. It means that if the feature ''f'' does not occur in the class you don't get an error (-1), as <e>RENAMING_A</e> does not consult a context class for its operations.

===CLASS_C===

A major change here affects the feature <e>constraint (i: INTEGER): TYPE_A</e>.
It is used to get the constraint of the formal at position ''i''. A new precondition has been added which states that it is only ok to call that feature if the formal has only one constraint. This is also the reason why currently it is not allowed to apply a renaming to a single constraint.
For the multi constraint case the feature <e>constraints (i: INTEGER): TYPE_SET_A</e> should be used instead. It returns a TYPE_SET_A instance which can possibly contain other formals.
==List of changes done==
This is an incomplete list of changes I've done which might need to be undone in the future.

* VGCC1 has a slightly adapted error message (which was wrong before) but is now also used for the case where one has two versions default_create in the creation constraint list.

Current implementation of multi constraint formals

2007-04-23T16:39:14Z

Seilerm:

[[Category:Compiler]]
{{UnderConstruction}}

==Introduction==
The first implementation of multi constraints is done and this article describes its current implementation status.

Let's take this example
<e>
MULTI [G -> {H, COMPARABLE rename is_equal as is_equal_cmp end},
H -> {NUMERIC rename default_create as default_create_num end, G}]
</e>
A type satisfying the constraint of ''G'' has the following properties:
* It conforms to whatever ''H'' is and therefore
** to <e>NUMERIC</e> and
** by recursion to itself (''G'')
* It conforms to its second constraint which is <e>COMPARABLE</e>.

A type satisfying the constraint of ''H'' has the following properties:
* It conforms to <e>NUMERIC</e>.
* It conforms to ''G'' and therefore
** by recursion to itself (''H'') and
** to <e>COMPARABLE</e>.

As ''G'' and ''H'' both have to conform to each other the only possibility to satisfy this is that ''G'' and ''H'' must be the same in the generic derivation. It does not make much sense to program something like that but it is part of the current implementation.

=== Feature calls ===

Let's have a look at the following feature written in class ''MULTI'':
<e>
feature
g: G

f: BOOLEAN
-- Sample feature
do
create g -- 1
Result := g.is_equal(g) -- 2
end
</e>
The following rules have to hold for each call on a multi constraint formal:
* Every feature which is called has exactly one class which is used as the static type for the call.

This is a major difference to the ECMA standard which allows a call to features which are available through different classes as long as it is the same feature. A definition of what the ''same feature'' means can be found [[Replication|here]].

In order to achieve that goal if a feature occurs with the same name in different classes one uses a rename clause and renames that feature. If there are name clashes between features and one does not want to call that feature a renaming is '''not''' needed.

As we perform calls to <e>default_create</e> (line 1 of <e>f</e>) and <e>is_equal</e> (line 2 of <e>f</e>, which are both features from <e>ANY</e> and each occurs as the same feature once in <e>COMPARABLE</e> and once in <e>NUMERIC</e>. We do this despite the fact that it is actually the same feature. The reason for this can be found in the new semantics of the dynamic binding described in the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard]. You may also want to have a look at the following [[Multiple_constraints|article]] which discusses the issue.

=== Renaming on formals ===

The current implementation rejects a rename clause which is applied to a formal. The following code is therefore currently rejected as H is a formal and we don't allow a renaming on it.
<e>
class MULTI[G -> {H rename is_equal as is_equal_prime end, ANY}, H -> ANY]
</e>

The rules implemented are chosen so that they are the most restrictive. This is to ensure that written code is likely to compile in the future where the rules might be more relaxed.

=== Creation without call to explicit creation feature ===
{{Note|This is not implemented in interim release 6.0.6.7358 or older.}}
<e>
class MULTI [G -> {COMPARABLE rename default_craete as default_create2 end,
NUMERIC} create default_create, default_create2 end]
</e>

An creation like <e>create g</e> where ''g'' is of type ''G'' yields an error as
there are two versions of ''default_create'' available.

==Implementation details==

The current implementation is pretty straightforward and tries to be as non-intrusive as possible. Most things rely on computation rather than on memory. For example there's no list which contains all features properly renamed but only a relatively small instance of <e>RENAMING_A</e> which contains a mapping of the name-ids.

The central classes to the current implementation are:
* <e>TYPE_SET_A</e>
* <e>RENAMED_TYPE_A</e>
* <e>RENAMING_A</e>
* <e>CONSTRAINING_TYPE_AS</e>
* and some changes to <e>CLASS_C</e>

The main tasks which have to be performed are:
* Type checking in particular type conformance.
* Feature lookup

Both tasks are provided by <e>TYPE_SET_A</e>.
===TYPE_SET_A===
====Conformance====
The feature <e>conform_to</e> inherited from <e>TYPE_A</e> can be used to check whether a type set conforms to another type which is possibly a type set as well.

* A type set conforms to another type if at least one type in the type
set conforms to the type.
* Another type conforms to a type set if it conforms to all types in the type set.
* A type set ''ts1'' conforms to a type set ''ts2'' if for each type ''t'' in ''ts2'' there is at least one type in ''ts1'' which conforms to ''t''.

If every type is regarded as a type set with one element one can simply always use the last rule.

====Feature lookup====
There are various features which provide this functionality. Their differences are mostly in the amount of information they provide. Of course the computation gets more expensive if the feature returns more information.
Currently the API is pretty much targeted to what the compiler needs.
There's a bunch of features of the family ''e_feature_state_*''/''feature_i_state_*'' which are used when most likely only one feature occurs.
As soon as you need more information the features of the family ''info_about_feature_*'' can help you to get all information about a certain feature for a given type set.

Now there is one more thing to add: As a type set which you obtain over <e>{CLASS_C}.constraints (a_formal_position)</e> can contain formals, which themselves can have constraints and therefore add more available features, one needs to compute somehow a "flat" version of the type set. This version cannot be used anymore for meaning full type checking but is perfectly suited to do feature queries.
<e>
class MULTI [G -> {H, I}, H -> COMPARABLE, I -> NUMERIC]
</e>
Consider now the following code which works on the <e>CLASS_C</e> object of class <e>MULTI</e> called <e>multi_class</e>

<e>
a_type_set_with_formals := multi_class.constraints (1)
-- a_type_set_with_formals: {H, I}
a_type_set_without_formals := a_type_set_with_formals.constraining_types (multi_class)
-- a_type_set_without_formals: {COMPARABLE, NUMERIC}
</e>

It basically gets rid of all formals (even recursive cases are handled correctly) and puts together a new type set which can be used for example to show all classes which provide features to a formal or to do feature lookup. The fact that there's no good reason to use it for conformance suggests that one refactors this class into two classes: One for type checking and one for feature lookup.

====Associated class====
This feature is no longer available and therefore exported to NONE. This is simply because there is no single associated class but many.
You can use the feature ''associated_classes'' instead and get a list of all associated classes.
However, the features applicable to the type set is not the same set as the features provided by each element of the ''associated_classes''. This is because one loses the renaming (class <e>RENAMING_A</e>) which is stored inside the <e>TYPE_SET_A</e> in each <e>RENAMED_TYPE_A</e> instance. This is why there are some places in the code where going from a <e>CLASS_C</e> instance to one of type <e>LIST [CLASS_C]</e> is not enough.

===RENAMED_TYPE_A===
The <e>RENAMED_TYPE_A</e> class basically encapsulates a <e>TYPE_A</e> object and a <e>RENAMING_A</e> object.
The fact that it is conform to TYPE_A opens the door for mistakes: Make sure that you use <e>{RENAMED_TYPE_A}.type</e> or <e>{RENAMED_TYPE_A}.actual_type</e> if your code makes assignment attempts, it is pretty much the same as with the family of the "like" types.

===RENAMING_A===
This is the class which provides features to handle the renaming which is applied to the features of the constraint type.

It's current implementation is based on a hash table and therefore only one way is efficient.

You can find out whether a specific feature is renamed by calling <e>is_feature_renamed</e>. There's also a predefined feature <e>renamed</e> which takes an integer argument and returns another one. The integer returned is either
* unchanged, if the feature is not renamed
* some other positive integer if the feature is renamed under the renaming
* -1 if the feature was renamed into something else (therefore it is not accessible)

However, this is only relative to the renaming and is not in the context of a specific class. It means that if the feature ''f'' does not occur in the class you don't get an error (-1), as <e>RENAMING_A</e> does not consult a context class for its operations.

===CLASS_C===

A major change here affects the feature <e>constraint (i: INTEGER): TYPE_A</e>.
It is used to get the constraint of the formal at position ''i''. A new precondition has been added which states that it is only ok to call that feature if the formal has only one constraint. This is also the reason why currently it is not allowed to apply a renaming to a single constraint.
For the multi constraint case the feature <e>constraints (i: INTEGER): TYPE_SET_A</e> should be used instead. It returns a TYPE_SET_A instance which can possibly contain other formals.
==List of changes done==
This is an incomplete list of changes I've done which might need to be undone in the future.

* VGCC1 has a slightly adapted error message (which was wrong before) but is now also used for the case where one has two versions default_create in the creation constraint list.

Covariance-aware assertions

2007-04-22T19:04:21Z

Seilerm: /* Unsatisfiable postcondition on catcalls */

ECMA Eiffel introduces covariance-aware assertions (section 8.10.4)). This is a change in assertions when covariant redefinition of feature argument occurs.

== Why do we need this? ==

When covariant argument redefinition occurs, some assertions may be invalidated through the change of an attached to a detached type. For example an assertion <e>x.is_empty</e> is not valid anymore after x is covariantly redefined since it is of a detachable type and could be Void.

{{Todo|Add other examples}}

== Problems with the mechanism ==

Let's look at an example:

<e>
class A

feature

f (x: ? ANY)
do
ensure
True
end

end

class B

inherit
A
redefine f end

feature

f (x: ? STRING)
do
end

end
</e>

Since the feature is covariantly redefined, the postcondition will go through the process described in section 8.10.4. The consequences are that each assertion will be changed to check for potential catcalls in the following way:

* Normal assertion: <e>True</e>
* Covariant-aware assertion: <e>({y: STRING} x) and then (True)</e>

So the full interface of the inherited feature is:

<e>
f (x: ? STRING)
ensure -- From A
({y: STRING} x) and then (True)
</e>

{{Note|The postcondition <e>True</e> could be replaced by any other postcondition. This just illustrates that the problem occurs on any feature since all features have an implicit postcondition ''True''.}}

=== Unsatisfiable postcondition on Void arguments ===

Now consider the following code block:

<e>
local
a: A
b: B
do
a := b
a.f (Void)
end
</e>

The caller of feature f in class A makes a valid call by passing Void as an argument. But the postcondition of the redefined feature f in class B will evaulate to false since the object test on the argument will evaluate to false.

In general, every covariance-aware assertion on an argument where Void would have been allowed (namely detached arguments) will invalidate the postcondition for a Void argument.

The problem is that the object test which actually should check for invalid arguments through cat calls will fail for Void even if it would be legal as an argument. Thus the covariance-aware assertion rule has to be changed to take Void into account if the argument which gets covariantly redefined is not an attached type and allows Void values.

For this the rule should make an object test for arguments which get redefined covariantly, but additionally allow Void values for detachable argument types. Thus the covariance-aware assertion has to look like:

* Normal assertion: <e>True</e>
* Covariant-aware assertion: <e>({y: STRING} x or x = Void) and then (True)</e>

=== Unsatisfiable postcondition on catcalls ===

Consider a second example where the argument type is attached in the parent feature:

<e>
class A

feature

g (x: ANY)
do
ensure
True
end

end

class B

inherit
A

feature

g (x: ? STRING)
do
if {y: STRING} x then
-- Do something with y
else
-- We had a catcall or a Void argument.
-- There is nothing to do here since
-- the inherited postcondition is 'True'
end
end

end
</e>

The argument get's detached, and any meaningful code in the redefined feature has to check for the type of the argument.

But again, the inherited assertion goes through the process to become covariance-aware:

* Normal assertion: <e>True</e>
* Covariant-aware assertion: <e>({y: STRING} x) and then (True)</e>

Now consider the following code block with a catcall:

<e>
local
a: A
b: B
do
a := b
a.g (5)
b.g (Void)
end
</e>

The covariance-aware postcondition again evaluates to <e>False</e>, no matter what the feature does. Thus in case of a cat-call the postcondition is violated in every case. Even in the case where <e>Void</e> is passed legally, the postcondition is violated (as described in the previous section).

The question here is, if we want to allow catcalls at all. Should they go trough then the programmer has to check them with an object test (which does not work if Void is passed), or should an exception be triggered by the runtime system. In the second case it surely should not be a postcondition violation.

== Possible solutions ==

To solve the first problem shown - when a valid Void argument is passed the covariance-aware assertion fails - the rules to create covariance-aware assertions have to be changed to take detachable arguments into account and allow the valid use of Void arguments.

To solve the second problem shown - on a catcall the postcondition is violated in every case - the rules also have to be changed ... (Todo: changed to what?)

== Catcalls in general ==

{{Todo|This part probably should get it's own page}}

The question remains what the system is supposed to do in a catcall at all:
* If catcalls have to be detected statically, the whole mechanism of redefining detachable is not necessary anyway and covariance-aware assertions have to be revised.
* If catcalls should be handled dynamically, there are two ways to do so:
** The program does not raise an exception on a catcall. In this case the programmer has to do an object-test to use covariantly redefined features (See also [[New CAT call|this]] page for an argument against this). Problems are raised with the covariance-aware assertions and their rules have to be changed not to invalidate postconditions in all cases.
** The program raises an exception on a catcall. If an exception should be raised, this better be the case on the entry to the call and not in the postcondition. So a runtime check could be introduced on any problematic feature call and raise an exception. This would also imply that the mechanism of redefining covariant features detachable is not necessary anymore since the runtime guarantees that all arguments are valid.

Preventing CAT calls in Generics

2007-04-20T04:27:00Z

Seilerm: /* How to generate the call signature for a given agent type */

[[Category:ECMA]]
{{UnderConstruction}}

==Introduction==

The problem with the way generics are implemented in Eiffel right now is that CAT calls can occur.
<e>
class PERSON
end

class STUDENT
inherit
PERSON
end

class EMPLOYEE
inherit
PERSON
end

class EMPLOYED_STUDENT
inherit
EMPLOYEE
STUDENT
end
</e>

<e>
local
l_person: PERSON
l_student: STUDENT
l_any_stack: STACK [PERSON]
l_student_stack: STACK [STUDENT]
do
l_person_stack := l_student_stack -- line 1
l_person_stack.put (l_person) -- line 2
l_student := l_student_stack.item -- line 3
</e>
Currently no static check will prohibit you from writing things like this. At runtime on ''line 2'' the first CAT call occurs, which most likely wont do any harm to a list. But the object returned by <e>item</e> on ''line 3'' is not of type <e>STUDENT</e> but of type <e>PERSON</e> and at least now we have a serious problem if one invokes features specific to a student on <e>l_student</e>.

The issue is that the <e>put</e> feature of <e>l_person_stack</e> allows you to put objects of type <e>PERSON</e> on the stack even though the actual type of the attached object is <e>STACK [STUDENT]</e> and is referenced by <e>l_student_stack</e> whose <e>item</e> feature guarantees, that the returned object will be of type <e>STUDENT</e>.
This solution will now extend the type system and the generic derivation of Eiffel in such away, that the type of a formal occurring as an argument in a feature declaration and the type of a formal occurring as a result type can be set independently. The type system will be extended with rules which allow only assignments between generic types if it cannot possibly lead to problems like the one mentioned above.

== Syntax ==

LIST [G] can be declared in the following way:
<e>
l_list: LIST [PERSON..EXMLPOYED_STUDENT]
</e>

<e>LIST[A]</e> is a shorthand for <e>LIST[A..A]</e>.
<e>LIST[A..]</e> is also a possible syntax.

Another syntax could look as follows:
<e>
<type_for_arguments>:<type_for_return_types>
</e>
This would more resemble an actual generated signature of a feature which looks initially like
<e>
class EXAMPLE [G]
feature
example (a_g: G): G
end
</e>

A type declaration with this syntax would look like:
<e>
local
l_example: EXAMPLE [EMLPOYED_STYDENT: STUDENT]
l_employed_student: EMPLOYED_STUDENT
l_person: PERSON
do
-- l_example.example (a_g: EMPLOYED_STUDENT): STUDENT
l_person := l_example.example (l_employed_student) -- valid
end
</e>
<e>LIST[:A]</e> is the equivalent to <e>LIST[A..]</e>.
<e>LIST[A]</e> is a shorthand for <e>LIST[A: A]</e>.

But let's stick with the initial syntax for now.

== Semantics ==

As we already pointed out, this solution is an extension to the type system. It helps you to proper derive an interface of a generic type.
For example an actual type parameter for G in <e>LIST [G]</e> is PERSON..EMPLOYED_STUDENT.
The interface generated by this derivation is simply that the first type (PERSON) is taken wherever G occurs as a return type.
The second type (EMPLOYED_STUDENT) is taken wherever G occurs as an argument type.

<e>
(generic derived) class LIST[PERSON..EMPLOYED_STUDENT]

put (v: EMPLOYED_STUDENT)

item: PERSON
</e>

If we encounter a form like LIST [A..] it simply means that no feature which has the formal in the argument can be called.

{{Note| Why do we need that?
We want to ensure that one has a read only list. One cannot use a <e>LIST [ANY..NONE]</e> because one would not be allowed to assign a <e>LIST [INTEGER]</e> to it. This is because one can put Void into a list of type <e>LIST [ANY..NONE]</e>, which is invalid for a list of integer as <e>INTEGER</e> is expanded.}}

== Validity ==

<e>LIST[<first_type>..<second_type>]</e>

Such a generic derivation is valid if:
* 1: the second type conforms to the constraint of the formal.
* 2: the second type conforms to the first type

==Conformance Rules==

We make another more abstract example to illustrate the conformance rules. They can easily be derived by applying the fact that its save for argument types to be contra-variant and for result types to be covariant. This is actually a very important as it is the basis where the conformance is based uppon.

Interface conformance rule:
An interface B is conform to an interface A if for every feature f_a in A
there is a corresponding feature f_b available from B and for each feature
the arguments of f_a conform to those of f_b and the result type of f_b is
conform to the one of f_a.

<e>
local
l_a: A
l_b: B
do
-- is legal if the interface conformance rule holds
l_a := l_b
end
</e>

===Example of an actual generic conformance table===

<e>
class T
end

class U
inherit T
-- no covariant feature redefinition
end
</e>

{| class="wikitable"
|-
| conforms to
! LIST [ANY]
! LIST [T]
! LIST [T..NONE]
! LIST [ANY..T]
! LIST [U]
|-
! LIST [ANY]
| true
| false
| false
| true
| false
|-
! LIST [T]
| false
| true
| true
| true
| false
|-
! LIST [T..NONE]
| false
| false
| true
| false
| false
|-
! LIST [ANY..T]
| false
| false
| false
| true
| false
|-
! LIST [U]
| false
| '''false'''
| true
| false
| true
|}

<e>
-- legal
T := LIST [T..NONE] .item
LIST [T..NONE] .put (Void)

-- illegal
U := LIST [T..NONE] .item
LIST [T..NONE] .put (T)

-- legal
LIST [ANY..T] .put (T)
LIST [ANY..T] .put (U)
ANY := LIST [ANY..T] .item

-- illegal
LIST [ANY..T] .put (ANY)
T := LIST [ANY..T] .item
</e>

==Agents==

The neat thing about this extension is, that there is no need to cut down the expressiveness of the agent mechanism to make them perfectly save to use with full support for all legal situations.

Procedure class:
<e>
class PROCEDURE [BASE_TYPE, OPEN_ARGS -> TUPLE []]
-- Signature of call is generated by the compiler. To visualize this we add _reflected to the argument tuple.
call (args: OPEN_ARGS_reflected)
do end

end
</e>

=== Agent example ===

Type declaration:
<e>
an_agent: PROCEDURE [ANY..NONE, TUPLE..TUPLE [ANY..T]] --> like agent (T)
-- This signature promises that the caller is going to give at least one argument which conforms to T.
-- Note: The signature for the call routine has to be reflected by the compiler into : TUPLE [T..]..NONE
-- This is because we can give a tuple containing more than one element and it element type has to conform to T.

-- legal
an_agent.call ([T])
an_agent.call ([T, ...])
an_agent.call ([U, ...])

-- illegal
an_agent.call ([])
</e>

Instantiation:
<e>
agent_empty := agent () do end --> PROCEDURE [ANY, TUPLE []]
agent_any := agent (a: ANY) do end --> PROCEDURE [ANY, TUPLE [ANY]]
agent_t := agent (t: T) do end --> PROCEDURE [ANY, TUPLE [T]]
agent_u := agent (u: U) do end --> PROCEDURE [ANY, TUPLE [U]]

-- legal
an_agent := agent_empty
an_agent := agent_any
an_agent := agent_t

-- illegal
an_agent := agent_u
</e>

There might be a concern about the fact that the compiler generates the signature of the call method. But I think that its not wrong to have compiler support for agents, as they are such a fundamental core concept that is simply important that one could sacrifice expressive power or type safety just to avoid explicit support from the compiler.

=== How to generate the call signature for a given agent type ===

To build the signature of the call routine one simply takes he second parameter and puts it as the first. As the second parameter we put nothing.

Example:
<e>
TUPLE [ANY..T, ANY..U, ANY..V]
</e>

leads to
<e>
TUPLE [T..,U..,V..]
</e>

This basically states that all I want is to be able to read an object of at least type T, U, V and that I'm not going to put anything into this tuple.

Class checking

2007-04-19T17:11:29Z

Seilerm:

==Introduction==

This page is intended to find consensus over something called differently in EiffelStudio and gec/gelint.

The subject for which a name is needed is the checking of all inherited features in the context of each descendant.

==Proposals==

===Proposal template===
====Pro====
====Contra====

Immutable Strings

2007-04-18T00:24:03Z

Seilerm: /* Issues with ANY.is_equal */

{{warning|This article under development and is not ready for any form of review.}}

Author: Paul Bates

[[Category:EiffelBase]]

==Introduction==
On the heals of a point raised on [http://www.eiffelroom.com/blog/colin_adams/read_only_strings eiffelroom] regarding read-only variants of an Eiffel <code>[eiffel, n]STRING</code>, this page has come about to discuss the possible options for introducing such new types.

The term read-only is not a fitting name so this page documents such string variants as being immutable with it's already implemented cousins <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> coined mutable.

==Rational==
There are a number of reason why Eiffel needs an immutable representation of a string, which no matter what should be able to be altered. Below explains the rationale for why immutable strings are required in a language, as for those reasons why they are there.

===EMCA STRING_8 and STRING_32 Are Not Constants===
Section 8.29 of the Eiffel ECMA specification details the declaration and use of constants in Eiffel. In section 8.29 the three Eiffel string forms are detailed as being constants. To be pedantic about the matter I extracted a dictional reference for the the word ''constant''.

''con·stant'' /ˈkɒnstənt/

–adjective
1. Not changing or varying; uniform; regular; invariable.

–noun
7. Something that does not or cannot change or vary.

ECMA details the use of the three <code>[eiffel, n]STRING</code> declaration variants as constants but in reality this is contracting to the definition, and misleading in true semantics. <code>[eiffel, n]STRING</code>s are mutable, "constants" are not. As a simple case example, take the following code snippet.

<code>[eiffel, n]
full_path: STRING_8
once
Result := template_path
Result.replace_sub_string_all ("$1", root_path)
ensure
result_attached: Result /= Void
not_result_is_empty: not Result.is_empty
end

template_path: STRING_8 = "$1\data\default.cfg"
</code>

The code demonstrates an all too common scenario. Once <code>[eiffel, n]full_path</code> has been called the contents of template_path are modified. Any other use of <code>[eiffel, n]template_path</code> will yield a "constant" value that differs from that declared. The EMCA specification indicates that declaration of <code>[eiffel, n]template_path</code> pertains to the specification of a constant attribute (8.29.2 and 8.29.3.)

<code>[eiffel, n]full_path</code>, with once function semantics, is never a constant but is evaluated on a single as-needed basis. full_path actually demonstrates yet another rationale for introducing immutable strings into Eiffel.

===Immutable Interfaces===

A second rationale is through good design of a class' exported interface. A good design will yield immutable exported members as not to seemingly violate such principles of object orientation. I note "seemly" violated because by technical reference such principles are not violated. The principle in reference is one that states - a class, and it's descendants, should be the only entities to modify a respective runtime instantiation internal state. No client should be permitted to perform such modifications - Technically STRING is a reference type so a qualified call, like append, made on a STRING object, is modifying the internal state of that STRING object. However STRING has special reverence that binds it with the likes of INTEGER, NATURAL and CHARACTER. It's an inbuilt rudimentary type that is seen to be "a value". Almost all other reference types are just objects and runtime with no real discernible value.

Current EiffelBase abstraction enabled authoring of immutable exported client interfaces, yet allow resident routines to manipulate the internals of an object's state.

<code>[eiffel, n]
feature -- Access

selected_indexes: BILINEAR [NATURAL]
-- Select item indexes
do
Result := internal_selected_indexes
ensure
result_attached: Result /= Void
end

feature {NONE} -- Implementation

internal_selected_indexes: ARRAYED_LIST [NATURAL]
-- Mutable version of `internal_selected_indexes'
</code>

selected_indexes permits clients to access a list of index positions but never allows any extending or removal of items from that structure. <code>[eiffel, n]internal_selected_indexes</code> is used internally to add or extend items based on some peripheral interaction. If the author wanted client to modified the result of selected_indexes then additional routines can be implemented on a fully or partially exported part of the class' interface. Such routines as <code>[eiffel, n]set_selected_indexes</code> could be implemented or <code>[eiffel, n]add_index</code> and the conversely <code>[eiffel, n]remove_index</code> could be implemented as a Delegate pattern implementation.

As it stands today, with only mutable strings, it is not possible to author such classes. A class attribute, or a once function, is open for modification by an unruly client, where it be accidental through a missing clone of a <code>[eiffel, n]STRING</code>, using twin, or through naivety. Either way, it's dangerous!

==Suggestions to Implementation==

There are a number of factors to consider before deciding on a implementation choice for immutable string. First and probably most importantly is compatibility. Compatibility raises concerns regarding the assignment of a mutable string to an immutable string, vice-versa and even back again.

==Compatibility==
Before any indicate of how mutable and immutable strings interacte there's needs to be a brief rundown of the possible ways they can interact. There's two schools of thought; Conformance or Conversion.

===Conformance or Conversion===
It has been mentioned that maybe an immutable string should conform to a mutable string, for optimization purposes. Respecting the possible choice for conformance it does not seem coherent that a mutable string is actually a specialized immutable string?! In addition, with conformance it would be entirely possible to reverse assign an immutable string to a mutable string, rendering any immutable client interface ineffective at preventing external modification.

The alternative to conformance would be to use an implicit conversion routine to convert the mutable string to an immutable one, on assignment or a pass through to a routine argument typed to an immutable string. Conversion, personally, seems the most correct route to follow.

===Examples===

For the purpose of illustration the following declarations will be used. <code>[eiffel, n]IMMUTABLE_STRING_8</code> is being introduced as a place holder for a immutable variant of the current mutable <code>[eiffel, n]IMMUTABLE_STRING_8</code> class.

<code>[eiffel]
ms1: STRING_8
ms2: STRING_8
is1: IMMUTABLE_STRING_8
</code>

The first topic is to determine how manifest string constants comply with mutable strings. The following lists all syntax valid operations based on the ECMA specification. The assignments are made using the types manifest constant specification in section 8.29.6.

<code>[eiffel]
1. ms1 := "Hello World"
2. ms1 := {STRING_8} "Hello World"
3. ms1 := {IMMUTABLE_STRING_8} "Hello World"
4. ms1 := once "Hello World"
</code>

In case '''1''' the compiler should recognize the assignment and create a <code>[eiffel]STRING_8</code> using the manifest string. No immutable string should be created. Case '''2''' is effectively the same as case '''1''', just more explicit. Case '''3''' introduces the immutable string. In this case the compiler should reject the call. Immutable strings cannot become mutable. If the conforming option for implement were to be chose then <code>[eiffel]ms1</code> would be set to <code>[eiffel]Void</code>. An immutable string has been created and it does not conform to <code>[eiffel]STRING_8</code>. Finally case '''4''' leaves room for explanation. In a world of Eiffel immutable strings a once string should behave in the same manner as case '''3'''. Currently it behaves like cases '''1''' and '''2'''.

<code>[eiffel]
1. is1 := "Hello Immutable World"
2. is1 := {STRING_8} "Hello Immutable World"
3. is1 := {IMMUTABLE_STRING_8} "Hello Immutable World"
4. is1 := once "Hello Immutable World"
</code>

In case '''1''' the compiler should recognize the assignment and create a <code>[eiffel]IMMUTABLE_STRING_8</code> using the manifest string. No mutable string should be created. Case '''2''' uses the mutable string. In this case the developer has explicitly requested that the manifest string be of an immutable type. The course of action is dictated by a choice between conformance or conversion. Case '''3''' is effectively the same as case '''1''', just more explicit. Finally case '''4''' leaves room for explanation. In a world of Eiffel immutable strings a once string should behave in the same manner as cases '''1''' and '''3'''. Currently there is no defined behavior for this.

===Using Conversion===
As stated conversion seems to be the winner. In discussing this with others at Eiffel Software it seems the vote is unanimous that conversion is the best option after all things considered. The road to using conversion as a mean to interop between strings is not a clear one. There are problems that need to be overcome.

====Fetching a Mutable String====
First and most rudimentary is the ability to fetch a mutable version of an immutable string. All that is needed is function to make the explicit conversion; <code>[eiffel, n]as_string_8</code> and <code>[eiffel, n]as_string_32</code> functions will have to be added to the immutable string class or be defined in a more abstract version of the class.

====Issues with ANY.is_equal====
With a non-conforming implementation of mutable and immutable strings <code>[eiffel, n]ANY.is_equal</code> as defined in ECMA will be broken.

ECMA's <code>[eiffel, n]is_equal</code> loosens the binds when it comes to comparing objects for equality. <code>[eiffel, n]is_equal</code>'s argument <code>[eiffel, n]other</code> is now of type <code>[eiffel, n]ANY</code> and not a CAT-call prone <code>[eiffel, n]like Current</code> anchored type. It's not desirable to compare immutable string with only immutable string, and the same is true for mutable strings and mutable strings. Functionality must be provided to compare either or for equality and <code>[eiffel, n]True</code> returned as a result when both strings contain the same chain of characters. To support this crucial scenario a common base for '''all''' string variants needs to be introduced. For the sake of clarity with names, this shall be referenced as <code>[eiffel, n]ABSTRACT_STRING</code> (see A Common Ancestor). <code>[eiffel, n]ABSTRACT_STRING</code> should covariantly redefine <code>[eiffel, n]ANY.is_equal</code> so it's <code>[eiffel, n]other</code> argument is of type <code>[eiffel, n]ABSTRACT_STRING</code>. This way strings can be compared without any need for conversion with more concrete versions of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]IMMUTABLE_STRING_8</code>. More importantly, no risk of CAT-calls.

The second and more dispelling problem is with the postconditions. <code>[eiffel, n]same_type</code> will fail! It's possible for immutable and mutable strings to be declared as being equal, after all most of the time it's the content a program wants to compare and not the object reference. It is an argumentative point if two related but different objects can be equal, with accordance to the EMCA informative text.

''"..default_is_equal is frozen, always returning the value of field-by-field identity comparison (for not-void other); any class may, on the other hand, redefine is_equal, in accordance with the pre- and postconditions, to reflect a more specific notion of equality."''

Should it really matter then that the objects being compared actually be of the same type, when the result of <code>[eiffel, n]is_equal</code> yields <code>[eiffel, n]True</code>? The post-conditions are too strong, forbidding two disparate from being compared in valid domain context.

====Optimizations====
The mutable versions of the string class should convert to, and cache, an immutable variant of a string upon an initial request. Once the mutable string's content is modified the cached immutable string is to invalidated. The next request to convert the mutable string to an immutable variant would yield a new immutable string reference.

====A Common Ancestor====
Just as <code>[eiffel, n]STRING_GENERAL</code> is available now, a more abstract implementation is required to implement the features available for all string variants. That is; mutable, immutable and 8 and 32 bit versions of each. In the interest of backwards compatibility the use of <code>[eiffel, n]STRING_GENERAL</code> is not a viable solution. A proposed <code>[eiffel, n]ABSTRACT_STRING</code> will instead be put forth for the real general purpose string class.

<code>[eiffel, n]ABSTRACT_STRING</code> should contain a number of the routines moved up <code>[eiffel, n]STRING_GENERAL</code> and STRING_GENERAL</code> will hence forth derived <code>[eiffel, n]ABSTRACT_STRING</code>. The routines that will not be resident in <code>[eiffel, n]ABSTRACT_STRING</code> will be anything pertaining to mutating the internal representation.

==Is There a Need to STRING_8 and STRING_32==
Of course in outlining such a proposal you have to ask the relevance of augments/patching (it depends on your views) Eiffel with immutable strings. Should Eiffel just have immutable strings? It's been discussed that there should be mutable and immutable variants of <code>[eiffel, n]STRING</code>. Deviating from this a moment and looking at the best possible scenario for implementing immutable strings - make mutable strings a thing of the past!

So many other languages have chosen to use a immutable string as their fundamental string type. For optimization in creating new strings or piecing parts of strings together a string builder is used. Under .NET there is the immutable <code>[csharp, n]System.String</code> and optimized builder <code>[csharp, n]System.Text.StringBuilder</code>. In Java the exact same story; <code>[java, n]String</code> is an immutable string and <code>[java, n]StringBuffer</code> is used to optimally create immutable strings.

Yes, choosing such a option would break existing code. But we have to respect that trying to patch rather than change, often causes more problems that breaking code. With code breaking changes there should always be assistants available to help user migrate.

As simple first step is to change all <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> into <code>[eiffel, n]STRING_BUILDER_8</code> and <code>[eiffel, n]STRING_BUILDER_32</code>, or indeed a unified <code>[eiffel, n]STRING_BUILDER</code> for manipulating any sized string. The breaking changes can be minimized and all future use of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> are known to be immutable.

Should Eiffel follow suit and depreciate the existing implementation of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code>, in order to favor immutable strings and string builder(s)?

Immutable Strings

2007-04-18T00:16:11Z

Seilerm: /* Conformance or Conversion */

{{warning|This article under development and is not ready for any form of review.}}

Author: Paul Bates

[[Category:EiffelBase]]

==Introduction==
On the heals of a point raised on [http://www.eiffelroom.com/blog/colin_adams/read_only_strings eiffelroom] regarding read-only variants of an Eiffel <code>[eiffel, n]STRING</code>, this page has come about to discuss the possible options for introducing such new types.

The term read-only is not a fitting name so this page documents such string variants as being immutable with it's already implemented cousins <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> coined mutable.

==Rational==
There are a number of reason why Eiffel needs an immutable representation of a string, which no matter what should be able to be altered. Below explains the rationale for why immutable strings are required in a language, as for those reasons why they are there.

===EMCA STRING_8 and STRING_32 Are Not Constants===
Section 8.29 of the Eiffel ECMA specification details the declaration and use of constants in Eiffel. In section 8.29 the three Eiffel string forms are detailed as being constants. To be pedantic about the matter I extracted a dictional reference for the the word ''constant''.

''con·stant'' /ˈkɒnstənt/

–adjective
1. Not changing or varying; uniform; regular; invariable.

–noun
7. Something that does not or cannot change or vary.

ECMA details the use of the three <code>[eiffel, n]STRING</code> declaration variants as constants but in reality this is contracting to the definition, and misleading in true semantics. <code>[eiffel, n]STRING</code>s are mutable, "constants" are not. As a simple case example, take the following code snippet.

<code>[eiffel, n]
full_path: STRING_8
once
Result := template_path
Result.replace_sub_string_all ("$1", root_path)
ensure
result_attached: Result /= Void
not_result_is_empty: not Result.is_empty
end

template_path: STRING_8 = "$1\data\default.cfg"
</code>

The code demonstrates an all too common scenario. Once <code>[eiffel, n]full_path</code> has been called the contents of template_path are modified. Any other use of <code>[eiffel, n]template_path</code> will yield a "constant" value that differs from that declared. The EMCA specification indicates that declaration of <code>[eiffel, n]template_path</code> pertains to the specification of a constant attribute (8.29.2 and 8.29.3.)

<code>[eiffel, n]full_path</code>, with once function semantics, is never a constant but is evaluated on a single as-needed basis. full_path actually demonstrates yet another rationale for introducing immutable strings into Eiffel.

===Immutable Interfaces===

A second rationale is through good design of a class' exported interface. A good design will yield immutable exported members as not to seemingly violate such principles of object orientation. I note "seemly" violated because by technical reference such principles are not violated. The principle in reference is one that states - a class, and it's descendants, should be the only entities to modify a respective runtime instantiation internal state. No client should be permitted to perform such modifications - Technically STRING is a reference type so a qualified call, like append, made on a STRING object, is modifying the internal state of that STRING object. However STRING has special reverence that binds it with the likes of INTEGER, NATURAL and CHARACTER. It's an inbuilt rudimentary type that is seen to be "a value". Almost all other reference types are just objects and runtime with no real discernible value.

Current EiffelBase abstraction enabled authoring of immutable exported client interfaces, yet allow resident routines to manipulate the internals of an object's state.

<code>[eiffel, n]
feature -- Access

selected_indexes: BILINEAR [NATURAL]
-- Select item indexes
do
Result := internal_selected_indexes
ensure
result_attached: Result /= Void
end

feature {NONE} -- Implementation

internal_selected_indexes: ARRAYED_LIST [NATURAL]
-- Mutable version of `internal_selected_indexes'
</code>

selected_indexes permits clients to access a list of index positions but never allows any extending or removal of items from that structure. <code>[eiffel, n]internal_selected_indexes</code> is used internally to add or extend items based on some peripheral interaction. If the author wanted client to modified the result of selected_indexes then additional routines can be implemented on a fully or partially exported part of the class' interface. Such routines as <code>[eiffel, n]set_selected_indexes</code> could be implemented or <code>[eiffel, n]add_index</code> and the conversely <code>[eiffel, n]remove_index</code> could be implemented as a Delegate pattern implementation.

As it stands today, with only mutable strings, it is not possible to author such classes. A class attribute, or a once function, is open for modification by an unruly client, where it be accidental through a missing clone of a <code>[eiffel, n]STRING</code>, using twin, or through naivety. Either way, it's dangerous!

==Suggestions to Implementation==

There are a number of factors to consider before deciding on a implementation choice for immutable string. First and probably most importantly is compatibility. Compatibility raises concerns regarding the assignment of a mutable string to an immutable string, vice-versa and even back again.

==Compatibility==
Before any indicate of how mutable and immutable strings interacte there's needs to be a brief rundown of the possible ways they can interact. There's two schools of thought; Conformance or Conversion.

===Conformance or Conversion===
It has been mentioned that maybe an immutable string should conform to a mutable string, for optimization purposes. Respecting the possible choice for conformance it does not seem coherent that a mutable string is actually a specialized immutable string?! In addition, with conformance it would be entirely possible to reverse assign an immutable string to a mutable string, rendering any immutable client interface ineffective at preventing external modification.

The alternative to conformance would be to use an implicit conversion routine to convert the mutable string to an immutable one, on assignment or a pass through to a routine argument typed to an immutable string. Conversion, personally, seems the most correct route to follow.

===Examples===

For the purpose of illustration the following declarations will be used. <code>[eiffel, n]IMMUTABLE_STRING_8</code> is being introduced as a place holder for a immutable variant of the current mutable <code>[eiffel, n]IMMUTABLE_STRING_8</code> class.

<code>[eiffel]
ms1: STRING_8
ms2: STRING_8
is1: IMMUTABLE_STRING_8
</code>

The first topic is to determine how manifest string constants comply with mutable strings. The following lists all syntax valid operations based on the ECMA specification. The assignments are made using the types manifest constant specification in section 8.29.6.

<code>[eiffel]
1. ms1 := "Hello World"
2. ms1 := {STRING_8} "Hello World"
3. ms1 := {IMMUTABLE_STRING_8} "Hello World"
4. ms1 := once "Hello World"
</code>

In case '''1''' the compiler should recognize the assignment and create a <code>[eiffel]STRING_8</code> using the manifest string. No immutable string should be created. Case '''2''' is effectively the same as case '''1''', just more explicit. Case '''3''' introduces the immutable string. In this case the compiler should reject the call. Immutable strings cannot become mutable. If the conforming option for implement were to be chose then <code>[eiffel]ms1</code> would be set to <code>[eiffel]Void</code>. An immutable string has been created and it does not conform to <code>[eiffel]STRING_8</code>. Finally case '''4''' leaves room for explanation. In a world of Eiffel immutable strings a once string should behave in the same manner as case '''3'''. Currently it behaves like cases '''1''' and '''2'''.

<code>[eiffel]
1. is1 := "Hello Immutable World"
2. is1 := {STRING_8} "Hello Immutable World"
3. is1 := {IMMUTABLE_STRING_8} "Hello Immutable World"
4. is1 := once "Hello Immutable World"
</code>

In case '''1''' the compiler should recognize the assignment and create a <code>[eiffel]IMMUTABLE_STRING_8</code> using the manifest string. No mutable string should be created. Case '''2''' uses the mutable string. In this case the developer has explicitly requested that the manifest string be of an immutable type. The course of action is dictated by a choice between conformance or conversion. Case '''3''' is effectively the same as case '''1''', just more explicit. Finally case '''4''' leaves room for explanation. In a world of Eiffel immutable strings a once string should behave in the same manner as cases '''1''' and '''3'''. Currently there is no defined behavior for this.

===Using Conversion===
As stated conversion seems to be the winner. In discussing this with others at Eiffel Software it seems the vote is unanimous that conversion is the best option after all things considered. The road to using conversion as a mean to interop between strings is not a clear one. There are problems that need to be overcome.

====Fetching a Mutable String====
First and most rudimentary is the ability to fetch a mutable version of an immutable string. All that is needed is function to make the explicit conversion; <code>[eiffel, n]as_string_8</code> and <code>[eiffel, n]as_string_32</code> functions will have to be added to the immutable string class or be defined in a more abstract version of the class.

====Issues with ANY.is_equal====
With a non-conforming implementation of mutable and immutable strings <code>[eiffel, n]ANY.is_equal</code> as defined in ECMA will be broken.

ECMA's <code>[eiffel, n]is_equal</code> loosens the binds when it comes to comparing objects for equality. <code>[eiffel, n]is_equal</code>'s argument <code>[eiffel, n]other</code> is now of type <code>[eiffel, n]ANY</code> and not a CAT-call prone <code>[eiffel, n]like Current</code> anchored type. It's not desirable to compare immutable string with only immutable string, and the same is true for mutable strings and mutable strings. Functionality must be provided to compare either or for equality and <code>[eiffel, n]True</code> returned as a result when both strings contain the same chain of characters. To support this crucial scenario a common base for '''all''' string variants needs to be introduced. For the sake of clarity with names, this shall be referenced as <code>[eiffel, n]ABSTRACT_STRING</code> (see A Common Ancestor). <code>[eiffel, n]ABSTRACT_STRING</code> should convariantly redefine <code>[eiffel, n]ANY.is_equal</code> so it's <code>[eiffel, n]other</code> argument is of type <code>[eiffel, n]ABSTRACT_STRING</code>. This way strings can be compared without any need for conversion with more concrete versions of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]IMMUTABLE_STRING_8</code>. More importantly, no risk of CAT-calls.

The second and more dispelling problem is with the postconditions. <code>[eiffel, n]same_type</code> will fail! It's possible for immutable and mutable strings to be declared as being equal, after all most of the time it's the content a program wants to compare and not the object reference. It is an argumentative point if two related but different objects can be equal, with accordance to the EMCA informative text.

''"..default_is_equal is frozen, always returning the value of field-by-field identity comparison (for not-void other); any class may, on the other hand, redefine is_equal, in accordance with the pre- and postconditions, to reflect a more specific notion of equality."''

Should it really matter then that the objects being compared actually be of the same type, when the result of <code>[eiffel, n]is_equal</code> yields <code>[eiffel, n]True</code>? The post-conditions are too strong, forbidding two disparate from being compared in valid domain context.

====Optimizations====
The mutable versions of the string class should convert to, and cache, an immutable variant of a string upon an initial request. Once the mutable string's content is modified the cached immutable string is to invalidated. The next request to convert the mutable string to an immutable variant would yield a new immutable string reference.

====A Common Ancestor====
Just as <code>[eiffel, n]STRING_GENERAL</code> is available now, a more abstract implementation is required to implement the features available for all string variants. That is; mutable, immutable and 8 and 32 bit versions of each. In the interest of backwards compatibility the use of <code>[eiffel, n]STRING_GENERAL</code> is not a viable solution. A proposed <code>[eiffel, n]ABSTRACT_STRING</code> will instead be put forth for the real general purpose string class.

<code>[eiffel, n]ABSTRACT_STRING</code> should contain a number of the routines moved up <code>[eiffel, n]STRING_GENERAL</code> and STRING_GENERAL</code> will hence forth derived <code>[eiffel, n]ABSTRACT_STRING</code>. The routines that will not be resident in <code>[eiffel, n]ABSTRACT_STRING</code> will be anything pertaining to mutating the internal representation.

==Is There a Need to STRING_8 and STRING_32==
Of course in outlining such a proposal you have to ask the relevance of augments/patching (it depends on your views) Eiffel with immutable strings. Should Eiffel just have immutable strings? It's been discussed that there should be mutable and immutable variants of <code>[eiffel, n]STRING</code>. Deviating from this a moment and looking at the best possible scenario for implementing immutable strings - make mutable strings a thing of the past!

So many other languages have chosen to use a immutable string as their fundamental string type. For optimization in creating new strings or piecing parts of strings together a string builder is used. Under .NET there is the immutable <code>[csharp, n]System.String</code> and optimized builder <code>[csharp, n]System.Text.StringBuilder</code>. In Java the exact same story; <code>[java, n]String</code> is an immutable string and <code>[java, n]StringBuffer</code> is used to optimally create immutable strings.

Yes, choosing such a option would break existing code. But we have to respect that trying to patch rather than change, often causes more problems that breaking code. With code breaking changes there should always be assistants available to help user migrate.

As simple first step is to change all <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> into <code>[eiffel, n]STRING_BUILDER_8</code> and <code>[eiffel, n]STRING_BUILDER_32</code>, or indeed a unified <code>[eiffel, n]STRING_BUILDER</code> for manipulating any sized string. The breaking changes can be minimized and all future use of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> are known to be immutable.

Should Eiffel follow suit and depreciate the existing implementation of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code>, in order to favor immutable strings and string builder(s)?

Immutable Strings

2007-04-18T00:14:18Z

Seilerm: /* Conformance or Conversion */

{{warning|This article under development and is not ready for any form of review.}}

Author: Paul Bates

[[Category:EiffelBase]]

==Introduction==
On the heals of a point raised on [http://www.eiffelroom.com/blog/colin_adams/read_only_strings eiffelroom] regarding read-only variants of an Eiffel <code>[eiffel, n]STRING</code>, this page has come about to discuss the possible options for introducing such new types.

The term read-only is not a fitting name so this page documents such string variants as being immutable with it's already implemented cousins <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> coined mutable.

==Rational==
There are a number of reason why Eiffel needs an immutable representation of a string, which no matter what should be able to be altered. Below explains the rationale for why immutable strings are required in a language, as for those reasons why they are there.

===EMCA STRING_8 and STRING_32 Are Not Constants===
Section 8.29 of the Eiffel ECMA specification details the declaration and use of constants in Eiffel. In section 8.29 the three Eiffel string forms are detailed as being constants. To be pedantic about the matter I extracted a dictional reference for the the word ''constant''.

''con·stant'' /ˈkɒnstənt/

–adjective
1. Not changing or varying; uniform; regular; invariable.

–noun
7. Something that does not or cannot change or vary.

ECMA details the use of the three <code>[eiffel, n]STRING</code> declaration variants as constants but in reality this is contracting to the definition, and misleading in true semantics. <code>[eiffel, n]STRING</code>s are mutable, "constants" are not. As a simple case example, take the following code snippet.

<code>[eiffel, n]
full_path: STRING_8
once
Result := template_path
Result.replace_sub_string_all ("$1", root_path)
ensure
result_attached: Result /= Void
not_result_is_empty: not Result.is_empty
end

template_path: STRING_8 = "$1\data\default.cfg"
</code>

The code demonstrates an all too common scenario. Once <code>[eiffel, n]full_path</code> has been called the contents of template_path are modified. Any other use of <code>[eiffel, n]template_path</code> will yield a "constant" value that differs from that declared. The EMCA specification indicates that declaration of <code>[eiffel, n]template_path</code> pertains to the specification of a constant attribute (8.29.2 and 8.29.3.)

<code>[eiffel, n]full_path</code>, with once function semantics, is never a constant but is evaluated on a single as-needed basis. full_path actually demonstrates yet another rationale for introducing immutable strings into Eiffel.

===Immutable Interfaces===

A second rationale is through good design of a class' exported interface. A good design will yield immutable exported members as not to seemingly violate such principles of object orientation. I note "seemly" violated because by technical reference such principles are not violated. The principle in reference is one that states - a class, and it's descendants, should be the only entities to modify a respective runtime instantiation internal state. No client should be permitted to perform such modifications - Technically STRING is a reference type so a qualified call, like append, made on a STRING object, is modifying the internal state of that STRING object. However STRING has special reverence that binds it with the likes of INTEGER, NATURAL and CHARACTER. It's an inbuilt rudimentary type that is seen to be "a value". Almost all other reference types are just objects and runtime with no real discernible value.

Current EiffelBase abstraction enabled authoring of immutable exported client interfaces, yet allow resident routines to manipulate the internals of an object's state.

<code>[eiffel, n]
feature -- Access

selected_indexes: BILINEAR [NATURAL]
-- Select item indexes
do
Result := internal_selected_indexes
ensure
result_attached: Result /= Void
end

feature {NONE} -- Implementation

internal_selected_indexes: ARRAYED_LIST [NATURAL]
-- Mutable version of `internal_selected_indexes'
</code>

selected_indexes permits clients to access a list of index positions but never allows any extending or removal of items from that structure. <code>[eiffel, n]internal_selected_indexes</code> is used internally to add or extend items based on some peripheral interaction. If the author wanted client to modified the result of selected_indexes then additional routines can be implemented on a fully or partially exported part of the class' interface. Such routines as <code>[eiffel, n]set_selected_indexes</code> could be implemented or <code>[eiffel, n]add_index</code> and the conversely <code>[eiffel, n]remove_index</code> could be implemented as a Delegate pattern implementation.

As it stands today, with only mutable strings, it is not possible to author such classes. A class attribute, or a once function, is open for modification by an unruly client, where it be accidental through a missing clone of a <code>[eiffel, n]STRING</code>, using twin, or through naivety. Either way, it's dangerous!

==Suggestions to Implementation==

There are a number of factors to consider before deciding on a implementation choice for immutable string. First and probably most importantly is compatibility. Compatibility raises concerns regarding the assignment of a mutable string to an immutable string, vice-versa and even back again.

==Compatibility==
Before any indicate of how mutable and immutable strings interacte there's needs to be a brief rundown of the possible ways they can interact. There's two schools of thought; Conformance or Conversion.

===Conformance or Conversion===
It has been mentioned that maybe an immutable string should conform to a mutable string, for optimization purposes. Respecting the possible choice for conformance it does not seem coherent that a mutable string is actually a specialize immutable string?! In addition, with conformance it would be entirely possible to reverse assign a immutable string to a mutable string, rendering any immutable client interface ineffective at preventing external modification.

The alternative to conformance would be to use an implicit conversion routines to convert the mutable string to an immutable one, on assignment or a pass through to a routine argument typed to an immutable string. Conversion, personally, seems the most correct route to follow.

===Examples===

For the purpose of illustration the following declarations will be used. <code>[eiffel, n]IMMUTABLE_STRING_8</code> is being introduced as a place holder for a immutable variant of the current mutable <code>[eiffel, n]IMMUTABLE_STRING_8</code> class.

<code>[eiffel]
ms1: STRING_8
ms2: STRING_8
is1: IMMUTABLE_STRING_8
</code>

The first topic is to determine how manifest string constants comply with mutable strings. The following lists all syntax valid operations based on the ECMA specification. The assignments are made using the types manifest constant specification in section 8.29.6.

<code>[eiffel]
1. ms1 := "Hello World"
2. ms1 := {STRING_8} "Hello World"
3. ms1 := {IMMUTABLE_STRING_8} "Hello World"
4. ms1 := once "Hello World"
</code>

In case '''1''' the compiler should recognize the assignment and create a <code>[eiffel]STRING_8</code> using the manifest string. No immutable string should be created. Case '''2''' is effectively the same as case '''1''', just more explicit. Case '''3''' introduces the immutable string. In this case the compiler should reject the call. Immutable strings cannot become mutable. If the conforming option for implement were to be chose then <code>[eiffel]ms1</code> would be set to <code>[eiffel]Void</code>. An immutable string has been created and it does not conform to <code>[eiffel]STRING_8</code>. Finally case '''4''' leaves room for explanation. In a world of Eiffel immutable strings a once string should behave in the same manner as case '''3'''. Currently it behaves like cases '''1''' and '''2'''.

<code>[eiffel]
1. is1 := "Hello Immutable World"
2. is1 := {STRING_8} "Hello Immutable World"
3. is1 := {IMMUTABLE_STRING_8} "Hello Immutable World"
4. is1 := once "Hello Immutable World"
</code>

In case '''1''' the compiler should recognize the assignment and create a <code>[eiffel]IMMUTABLE_STRING_8</code> using the manifest string. No mutable string should be created. Case '''2''' uses the mutable string. In this case the developer has explicitly requested that the manifest string be of an immutable type. The course of action is dictated by a choice between conformance or conversion. Case '''3''' is effectively the same as case '''1''', just more explicit. Finally case '''4''' leaves room for explanation. In a world of Eiffel immutable strings a once string should behave in the same manner as cases '''1''' and '''3'''. Currently there is no defined behavior for this.

===Using Conversion===
As stated conversion seems to be the winner. In discussing this with others at Eiffel Software it seems the vote is unanimous that conversion is the best option after all things considered. The road to using conversion as a mean to interop between strings is not a clear one. There are problems that need to be overcome.

====Fetching a Mutable String====
First and most rudimentary is the ability to fetch a mutable version of an immutable string. All that is needed is function to make the explicit conversion; <code>[eiffel, n]as_string_8</code> and <code>[eiffel, n]as_string_32</code> functions will have to be added to the immutable string class or be defined in a more abstract version of the class.

====Issues with ANY.is_equal====
With a non-conforming implementation of mutable and immutable strings <code>[eiffel, n]ANY.is_equal</code> as defined in ECMA will be broken.

ECMA's <code>[eiffel, n]is_equal</code> loosens the binds when it comes to comparing objects for equality. <code>[eiffel, n]is_equal</code>'s argument <code>[eiffel, n]other</code> is now of type <code>[eiffel, n]ANY</code> and not a CAT-call prone <code>[eiffel, n]like Current</code> anchored type. It's not desirable to compare immutable string with only immutable string, and the same is true for mutable strings and mutable strings. Functionality must be provided to compare either or for equality and <code>[eiffel, n]True</code> returned as a result when both strings contain the same chain of characters. To support this crucial scenario a common base for '''all''' string variants needs to be introduced. For the sake of clarity with names, this shall be referenced as <code>[eiffel, n]ABSTRACT_STRING</code> (see A Common Ancestor). <code>[eiffel, n]ABSTRACT_STRING</code> should convariantly redefine <code>[eiffel, n]ANY.is_equal</code> so it's <code>[eiffel, n]other</code> argument is of type <code>[eiffel, n]ABSTRACT_STRING</code>. This way strings can be compared without any need for conversion with more concrete versions of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]IMMUTABLE_STRING_8</code>. More importantly, no risk of CAT-calls.

The second and more dispelling problem is with the postconditions. <code>[eiffel, n]same_type</code> will fail! It's possible for immutable and mutable strings to be declared as being equal, after all most of the time it's the content a program wants to compare and not the object reference. It is an argumentative point if two related but different objects can be equal, with accordance to the EMCA informative text.

''"..default_is_equal is frozen, always returning the value of field-by-field identity comparison (for not-void other); any class may, on the other hand, redefine is_equal, in accordance with the pre- and postconditions, to reflect a more specific notion of equality."''

Should it really matter then that the objects being compared actually be of the same type, when the result of <code>[eiffel, n]is_equal</code> yields <code>[eiffel, n]True</code>? The post-conditions are too strong, forbidding two disparate from being compared in valid domain context.

====Optimizations====
The mutable versions of the string class should convert to, and cache, an immutable variant of a string upon an initial request. Once the mutable string's content is modified the cached immutable string is to invalidated. The next request to convert the mutable string to an immutable variant would yield a new immutable string reference.

====A Common Ancestor====
Just as <code>[eiffel, n]STRING_GENERAL</code> is available now, a more abstract implementation is required to implement the features available for all string variants. That is; mutable, immutable and 8 and 32 bit versions of each. In the interest of backwards compatibility the use of <code>[eiffel, n]STRING_GENERAL</code> is not a viable solution. A proposed <code>[eiffel, n]ABSTRACT_STRING</code> will instead be put forth for the real general purpose string class.

<code>[eiffel, n]ABSTRACT_STRING</code> should contain a number of the routines moved up <code>[eiffel, n]STRING_GENERAL</code> and STRING_GENERAL</code> will hence forth derived <code>[eiffel, n]ABSTRACT_STRING</code>. The routines that will not be resident in <code>[eiffel, n]ABSTRACT_STRING</code> will be anything pertaining to mutating the internal representation.

==Is There a Need to STRING_8 and STRING_32==
Of course in outlining such a proposal you have to ask the relevance of augments/patching (it depends on your views) Eiffel with immutable strings. Should Eiffel just have immutable strings? It's been discussed that there should be mutable and immutable variants of <code>[eiffel, n]STRING</code>. Deviating from this a moment and looking at the best possible scenario for implementing immutable strings - make mutable strings a thing of the past!

So many other languages have chosen to use a immutable string as their fundamental string type. For optimization in creating new strings or piecing parts of strings together a string builder is used. Under .NET there is the immutable <code>[csharp, n]System.String</code> and optimized builder <code>[csharp, n]System.Text.StringBuilder</code>. In Java the exact same story; <code>[java, n]String</code> is an immutable string and <code>[java, n]StringBuffer</code> is used to optimally create immutable strings.

Yes, choosing such a option would break existing code. But we have to respect that trying to patch rather than change, often causes more problems that breaking code. With code breaking changes there should always be assistants available to help user migrate.

As simple first step is to change all <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> into <code>[eiffel, n]STRING_BUILDER_8</code> and <code>[eiffel, n]STRING_BUILDER_32</code>, or indeed a unified <code>[eiffel, n]STRING_BUILDER</code> for manipulating any sized string. The breaking changes can be minimized and all future use of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> are known to be immutable.

Should Eiffel follow suit and depreciate the existing implementation of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code>, in order to favor immutable strings and string builder(s)?

Immutable Strings

2007-04-18T00:13:26Z

Seilerm: /* Conformance or Conversion */

{{warning|This article under development and is not ready for any form of review.}}

Author: Paul Bates

[[Category:EiffelBase]]

==Introduction==
On the heals of a point raised on [http://www.eiffelroom.com/blog/colin_adams/read_only_strings eiffelroom] regarding read-only variants of an Eiffel <code>[eiffel, n]STRING</code>, this page has come about to discuss the possible options for introducing such new types.

The term read-only is not a fitting name so this page documents such string variants as being immutable with it's already implemented cousins <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> coined mutable.

==Rational==
There are a number of reason why Eiffel needs an immutable representation of a string, which no matter what should be able to be altered. Below explains the rationale for why immutable strings are required in a language, as for those reasons why they are there.

===EMCA STRING_8 and STRING_32 Are Not Constants===
Section 8.29 of the Eiffel ECMA specification details the declaration and use of constants in Eiffel. In section 8.29 the three Eiffel string forms are detailed as being constants. To be pedantic about the matter I extracted a dictional reference for the the word ''constant''.

''con·stant'' /ˈkɒnstənt/

–adjective
1. Not changing or varying; uniform; regular; invariable.

–noun
7. Something that does not or cannot change or vary.

ECMA details the use of the three <code>[eiffel, n]STRING</code> declaration variants as constants but in reality this is contracting to the definition, and misleading in true semantics. <code>[eiffel, n]STRING</code>s are mutable, "constants" are not. As a simple case example, take the following code snippet.

<code>[eiffel, n]
full_path: STRING_8
once
Result := template_path
Result.replace_sub_string_all ("$1", root_path)
ensure
result_attached: Result /= Void
not_result_is_empty: not Result.is_empty
end

template_path: STRING_8 = "$1\data\default.cfg"
</code>

The code demonstrates an all too common scenario. Once <code>[eiffel, n]full_path</code> has been called the contents of template_path are modified. Any other use of <code>[eiffel, n]template_path</code> will yield a "constant" value that differs from that declared. The EMCA specification indicates that declaration of <code>[eiffel, n]template_path</code> pertains to the specification of a constant attribute (8.29.2 and 8.29.3.)

<code>[eiffel, n]full_path</code>, with once function semantics, is never a constant but is evaluated on a single as-needed basis. full_path actually demonstrates yet another rationale for introducing immutable strings into Eiffel.

===Immutable Interfaces===

A second rationale is through good design of a class' exported interface. A good design will yield immutable exported members as not to seemingly violate such principles of object orientation. I note "seemly" violated because by technical reference such principles are not violated. The principle in reference is one that states - a class, and it's descendants, should be the only entities to modify a respective runtime instantiation internal state. No client should be permitted to perform such modifications - Technically STRING is a reference type so a qualified call, like append, made on a STRING object, is modifying the internal state of that STRING object. However STRING has special reverence that binds it with the likes of INTEGER, NATURAL and CHARACTER. It's an inbuilt rudimentary type that is seen to be "a value". Almost all other reference types are just objects and runtime with no real discernible value.

Current EiffelBase abstraction enabled authoring of immutable exported client interfaces, yet allow resident routines to manipulate the internals of an object's state.

<code>[eiffel, n]
feature -- Access

selected_indexes: BILINEAR [NATURAL]
-- Select item indexes
do
Result := internal_selected_indexes
ensure
result_attached: Result /= Void
end

feature {NONE} -- Implementation

internal_selected_indexes: ARRAYED_LIST [NATURAL]
-- Mutable version of `internal_selected_indexes'
</code>

selected_indexes permits clients to access a list of index positions but never allows any extending or removal of items from that structure. <code>[eiffel, n]internal_selected_indexes</code> is used internally to add or extend items based on some peripheral interaction. If the author wanted client to modified the result of selected_indexes then additional routines can be implemented on a fully or partially exported part of the class' interface. Such routines as <code>[eiffel, n]set_selected_indexes</code> could be implemented or <code>[eiffel, n]add_index</code> and the conversely <code>[eiffel, n]remove_index</code> could be implemented as a Delegate pattern implementation.

As it stands today, with only mutable strings, it is not possible to author such classes. A class attribute, or a once function, is open for modification by an unruly client, where it be accidental through a missing clone of a <code>[eiffel, n]STRING</code>, using twin, or through naivety. Either way, it's dangerous!

==Suggestions to Implementation==

There are a number of factors to consider before deciding on a implementation choice for immutable string. First and probably most importantly is compatibility. Compatibility raises concerns regarding the assignment of a mutable string to an immutable string, vice-versa and even back again.

==Compatibility==
Before any indicate of how mutable and immutable strings interacte there's needs to be a brief rundown of the possible ways they can interact. There's two schools of thought; Conformance or Conversion.

===Conformance or Conversion===
It has been mentioned that maybe an immutable string should conform to a mutable string, for optimization purposes. Respecting the possible choice for conformance it does not seem coherent that a mutable string is actually a specialize immutable string?! In addition, with conformance it would be entirely possible to to reverse assign a immutable string to a mutable string, rendering any immutable client interface ineffective at preventing external modification.

The alternative to conformance would be to use an implicit conversion routines to convert the mutable string to an immutable one, on assignment or a pass through to a routine argument typed to an immutable string. Conversion, personally, seems the most correct route to follow.

===Examples===

For the purpose of illustration the following declarations will be used. <code>[eiffel, n]IMMUTABLE_STRING_8</code> is being introduced as a place holder for a immutable variant of the current mutable <code>[eiffel, n]IMMUTABLE_STRING_8</code> class.

<code>[eiffel]
ms1: STRING_8
ms2: STRING_8
is1: IMMUTABLE_STRING_8
</code>

The first topic is to determine how manifest string constants comply with mutable strings. The following lists all syntax valid operations based on the ECMA specification. The assignments are made using the types manifest constant specification in section 8.29.6.

<code>[eiffel]
1. ms1 := "Hello World"
2. ms1 := {STRING_8} "Hello World"
3. ms1 := {IMMUTABLE_STRING_8} "Hello World"
4. ms1 := once "Hello World"
</code>

In case '''1''' the compiler should recognize the assignment and create a <code>[eiffel]STRING_8</code> using the manifest string. No immutable string should be created. Case '''2''' is effectively the same as case '''1''', just more explicit. Case '''3''' introduces the immutable string. In this case the compiler should reject the call. Immutable strings cannot become mutable. If the conforming option for implement were to be chose then <code>[eiffel]ms1</code> would be set to <code>[eiffel]Void</code>. An immutable string has been created and it does not conform to <code>[eiffel]STRING_8</code>. Finally case '''4''' leaves room for explanation. In a world of Eiffel immutable strings a once string should behave in the same manner as case '''3'''. Currently it behaves like cases '''1''' and '''2'''.

<code>[eiffel]
1. is1 := "Hello Immutable World"
2. is1 := {STRING_8} "Hello Immutable World"
3. is1 := {IMMUTABLE_STRING_8} "Hello Immutable World"
4. is1 := once "Hello Immutable World"
</code>

In case '''1''' the compiler should recognize the assignment and create a <code>[eiffel]IMMUTABLE_STRING_8</code> using the manifest string. No mutable string should be created. Case '''2''' uses the mutable string. In this case the developer has explicitly requested that the manifest string be of an immutable type. The course of action is dictated by a choice between conformance or conversion. Case '''3''' is effectively the same as case '''1''', just more explicit. Finally case '''4''' leaves room for explanation. In a world of Eiffel immutable strings a once string should behave in the same manner as cases '''1''' and '''3'''. Currently there is no defined behavior for this.

===Using Conversion===
As stated conversion seems to be the winner. In discussing this with others at Eiffel Software it seems the vote is unanimous that conversion is the best option after all things considered. The road to using conversion as a mean to interop between strings is not a clear one. There are problems that need to be overcome.

====Fetching a Mutable String====
First and most rudimentary is the ability to fetch a mutable version of an immutable string. All that is needed is function to make the explicit conversion; <code>[eiffel, n]as_string_8</code> and <code>[eiffel, n]as_string_32</code> functions will have to be added to the immutable string class or be defined in a more abstract version of the class.

====Issues with ANY.is_equal====
With a non-conforming implementation of mutable and immutable strings <code>[eiffel, n]ANY.is_equal</code> as defined in ECMA will be broken.

ECMA's <code>[eiffel, n]is_equal</code> loosens the binds when it comes to comparing objects for equality. <code>[eiffel, n]is_equal</code>'s argument <code>[eiffel, n]other</code> is now of type <code>[eiffel, n]ANY</code> and not a CAT-call prone <code>[eiffel, n]like Current</code> anchored type. It's not desirable to compare immutable string with only immutable string, and the same is true for mutable strings and mutable strings. Functionality must be provided to compare either or for equality and <code>[eiffel, n]True</code> returned as a result when both strings contain the same chain of characters. To support this crucial scenario a common base for '''all''' string variants needs to be introduced. For the sake of clarity with names, this shall be referenced as <code>[eiffel, n]ABSTRACT_STRING</code> (see A Common Ancestor). <code>[eiffel, n]ABSTRACT_STRING</code> should convariantly redefine <code>[eiffel, n]ANY.is_equal</code> so it's <code>[eiffel, n]other</code> argument is of type <code>[eiffel, n]ABSTRACT_STRING</code>. This way strings can be compared without any need for conversion with more concrete versions of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]IMMUTABLE_STRING_8</code>. More importantly, no risk of CAT-calls.

The second and more dispelling problem is with the postconditions. <code>[eiffel, n]same_type</code> will fail! It's possible for immutable and mutable strings to be declared as being equal, after all most of the time it's the content a program wants to compare and not the object reference. It is an argumentative point if two related but different objects can be equal, with accordance to the EMCA informative text.

''"..default_is_equal is frozen, always returning the value of field-by-field identity comparison (for not-void other); any class may, on the other hand, redefine is_equal, in accordance with the pre- and postconditions, to reflect a more specific notion of equality."''

Should it really matter then that the objects being compared actually be of the same type, when the result of <code>[eiffel, n]is_equal</code> yields <code>[eiffel, n]True</code>? The post-conditions are too strong, forbidding two disparate from being compared in valid domain context.

====Optimizations====
The mutable versions of the string class should convert to, and cache, an immutable variant of a string upon an initial request. Once the mutable string's content is modified the cached immutable string is to invalidated. The next request to convert the mutable string to an immutable variant would yield a new immutable string reference.

====A Common Ancestor====
Just as <code>[eiffel, n]STRING_GENERAL</code> is available now, a more abstract implementation is required to implement the features available for all string variants. That is; mutable, immutable and 8 and 32 bit versions of each. In the interest of backwards compatibility the use of <code>[eiffel, n]STRING_GENERAL</code> is not a viable solution. A proposed <code>[eiffel, n]ABSTRACT_STRING</code> will instead be put forth for the real general purpose string class.

<code>[eiffel, n]ABSTRACT_STRING</code> should contain a number of the routines moved up <code>[eiffel, n]STRING_GENERAL</code> and STRING_GENERAL</code> will hence forth derived <code>[eiffel, n]ABSTRACT_STRING</code>. The routines that will not be resident in <code>[eiffel, n]ABSTRACT_STRING</code> will be anything pertaining to mutating the internal representation.

==Is There a Need to STRING_8 and STRING_32==
Of course in outlining such a proposal you have to ask the relevance of augments/patching (it depends on your views) Eiffel with immutable strings. Should Eiffel just have immutable strings? It's been discussed that there should be mutable and immutable variants of <code>[eiffel, n]STRING</code>. Deviating from this a moment and looking at the best possible scenario for implementing immutable strings - make mutable strings a thing of the past!

So many other languages have chosen to use a immutable string as their fundamental string type. For optimization in creating new strings or piecing parts of strings together a string builder is used. Under .NET there is the immutable <code>[csharp, n]System.String</code> and optimized builder <code>[csharp, n]System.Text.StringBuilder</code>. In Java the exact same story; <code>[java, n]String</code> is an immutable string and <code>[java, n]StringBuffer</code> is used to optimally create immutable strings.

Yes, choosing such a option would break existing code. But we have to respect that trying to patch rather than change, often causes more problems that breaking code. With code breaking changes there should always be assistants available to help user migrate.

As simple first step is to change all <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> into <code>[eiffel, n]STRING_BUILDER_8</code> and <code>[eiffel, n]STRING_BUILDER_32</code>, or indeed a unified <code>[eiffel, n]STRING_BUILDER</code> for manipulating any sized string. The breaking changes can be minimized and all future use of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> are known to be immutable.

Should Eiffel follow suit and depreciate the existing implementation of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code>, in order to favor immutable strings and string builder(s)?

EiffelStudio 6.0 Releases

2007-04-16T21:07:48Z

Seilerm: /* 6.0.x */

[[Category:Releases]]__NOTOC__{{ReleaseHistoryHeader}}

= EiffelStudio 6.0.x Releases=

==6.0.x==
Placeholder for new stuff since last intermediate release.
===New features===
* estudio: {{Red|Replaced all native tool bars (EV_TOOL_BAR) with Smart Docking library tool bars (SD_TOOL_BAR).}}

===Feature removed===
===Bug fixes===
* EiffelStore: Fixed bug#12478: SQL_SCAN is made generic to overcome a creation readiness problem. This is a breaking change and you might need to update your code.
* docking: Fixed bug#12389: "Reset tools layout" in debug mode does not do what I am expecting
===User changes===
===Developer changes===

==6.0.6.7849 (April 15th 2007)==
===New features===
* compiler: The notion of creation readiness according to ECMA Eiffel standard (2nd edition, chapter 8.12.12) is implemented.
===Feature removed===
===Bug fixes===
* compiler: Fixed bug#12464: If a generic derivation in a deferred class uses `like Current' as generic parameter the creation constraints are not enforced on that particular formal.
* debugger: Completed implementation for dotnet system: bug#12435: Evaluating an expression still checks for invariant.
* debugger: Fixed bug#12435: Evaluating an expression still checks for invariant
* debugger: Now it is possible to disable/restore assertion checking during debugging in classic AND dotnet system.
* debugger: Fixed bug#12461: "Run Workbench" fails if no environment variable had been added.
* debugger: Fixed bug#12442: Selecting Debug/Exception handling for uncompiled project causes crash
* debugger: Fixed bug#12443: Run Workbench button in Debugging Options window does not work when app melted
* studio: Improved memory management.

===User changes===
===Developer changes===

==6.0.6.7775 (April 9th 2007)==
===New feature===
* vision2: ability to save an EV_PIXEL_BUFFER or to convert it to EV_PIXMAP.
* wel: {{Red|Added ability to convert image formats among all image formats on Windows (using WEL_GDIP_BITMAP).}}

===Bug fixes===
* debugger: Fixed bug#12435: Evaluating an expression still checks for invariant (classic only)
* debugger: Fixed bug#12443: Run Workbench button in Debugging Options window does not work when app melted
* vision2: Fixed bug bug#12113: I'd like to be able to save an EV_PIXEL_BUFFER into a file
* estudio: Fixed bug bug#12437: Previous docking layout are not valid

===Developer changes===
* Set .NET namespaces on all ISE libraries to be as terse and coherent as possible.
* .NET precompiled libraries binary names have been changed to fit present naming for .NET assemblies.

==6.0.6.7670 (April 1st 2007)==
===New features===
* studio: {{Red|Added ability to add new classes/clusters/assemblies early on in the compilation phase instead of waiting for a successful compilation.}}

===Bug fixes===
* dotnet: {{Red|Implemented suggestion from [[.NET_Namespace_Generation]].}}
* dotnet: Fixed bug#12433 where editing a class in EiffelStudio would change its generated namespace and thus invalidating the generated assembly (recompilation from scratch was necessary).
* Vision2: {{Red|Made sure that Windows and Unix behave the same way regarding widget navigation when one has set the ''default_key_processing_handler''. The behavior is that if it is set, then the tab processing will be disabled if it returns True.}}
*debugger: Fixed (again) bug#12371: Feature Relation window not scrolled to current line in debugger
*debugger: Implemented suggestion bug#12395 :No splitter by default
*debugger: Added start workbench and finalized system on Debugging option dialogs
*debugger: Fixed bug#11688: Compiling all classes under .NET with EXE generation hangs debugger
*estudio: Fixed bug#12203: Open Layout window disappears first time View/Open Layout is selected
*estudio: Fixed bug#12164: Large Fonts not respected in all widgets
*estudio: Fixed bug#12121: Wrong cursor if undock window operation in progress when compile ends
*estudio: Fixed bug#12036: Enter on a category in the Features tool does not focus the Editor
*estudio: Fixed bug#12104: Docked tracking preference ignored
*estudio: Fixed bug#12134: Auto Hide button should have different tooltips for enable/disable
*estudio: Fixed bug#12327: Closing Editor tab makes Clickable, Flat etc buttons insensitive
*docking: Fixed bug#12103: Estudio doesn't remember layout correctly if force debugger mode or maximize a tool
*docking: Fixed bug#12241: Hiding Address tool bar and reshowing it causes it to appear on Project tool bar row
*docking: Fixed bug#12260: Hiding toolbars leaves vacant space at bottom
*docking: Fixed bug#12114: Bringing up undocked window via View/Tools unmaximizes other too

===User changes===

===Developer changes===
*visioon2: Added new class EV_BEEP which can make system default beeps.

==6.0.6.7522 (March 25th 2007)==
===New features===
* studio: Add assembly dialog assembly entires are now placed in columns. Added columns for the assembly path and processor architecture.
* studio: {{Red| Added support for multi constraint code completion.}}

===Bug fixes===
* debugger: Fixed bug#11558 about evaluation of expressions involving NATURAL_XY values
* installer: (Windows) Fixed bitmap scaling issue for large fonts.
* Fixed the problem that Precursor {CLASS}.* only showed once routines.
* Fixed the problem that Result [i].* didn't work.
* Fixed the problem that Precursor {NEW_CLASS_3} [1].* didn't work.
* Fixed the problem that {INTEGER}.max_value.* didn't work.
* Fixed bug#12323 changing class name and then canceling Class Rename crashes estudio.
* Fixed bug#12331 Windows window showed two windows instead of one after exit and restart.
* Fixed bug#12347 that deleting a class displayed in an editor tab caused crash.
* Fixed a bug that initial dropping a cluster to diagram tool did nothing.
* Fixed bug#12299 that compiling lost diagram tool when targeted to a cluster.
* Fixed bug#12355 that selecting homonyms format for feature caused crash.
* Fixed the bug that shortcut for an initial or edited external command did not work.
* Fixed bug#11879 that show all docking indicators preference only respected when setting it.
* Fixed bug#12324 that main window resizes after loading project.
* Fixed bug#12118 that closing auto hidden tools during debugging leads to estudio crash.
* Fixed bug#12120 that particular docking layout causes crash in {SD_STATE_VOID}.move_to_docking_zone.
* Fixed bug#12339 that crash when rearranging editor tabs using mouse.
* Fixed bug#12235 that toolbar text blurs when exposed on linux.
* Fixed Eiffel Studio starting flicker problem, there is only 1 time flicker during the whole Eiffel Studio starting process now.

==6.0.6.7358 (March 18th 2007)==
===New features===
* studio: Added configurable shortcuts for history back and forth.
* studio: Added ability to remember show/hide formatting marks status.
* studio: Made Eiffel Studio can open into debug mode directly.
* studio: Disable fading effects for Eiffel Studio splash screen and disabled auto hide animations on remote desktop.
* debugger: new object viewer tool. (to replace the pretty or expanded display dialog)
* compiler: {{Red|Added support for multiple constraints in formal generic parameters.}}
* docking: Made docking library title bar drawing text position care about font size.

===Bug fixes===
* compiler: Fixed issue with incorrect labeled tuples which were not detected in signature of features (see eweasel test#tuple008).
* compiler: Fixed crash when checking an incorrect labeled tuple (e.g. TUPLE [a, a: INTEGER]) (see eweasel test#tuple009).
* studio: {{Red|Fixed bug#12083 where classes in override clusters would not get recompiled properly when automatically saved by EiffelStudio when requesting a compilation.}}
* studio: Fixed display of public key token on add assembly dialog.
* studio: Improved show/hide formatting marks command. This command only functioned on current editor and when current editor switched the name was not displayed correctly. Now it functions on all editors of current window.
* studio: Fixed bug#12256 that dependency tool could not close.
* studio: Fixed bug#12261 that find was broken, and added Home/End actions to the report grid.
* studio: Fixed bug#12264 that first column of preference grid was too narrow.
* studio: Fixed a bug that Alt+Left/Alt+Right didn't function on diagram tool and dependency tool.
* studio: Fixed a bug that address history forth command was always disabled in diagram tool.
* studio: Fixed bug#12258 that completion window was brought up by dot after a number.
* studio: Fixed the bug that shortcut for class completion triggered feature completion window in completable text fields (i.e. Watch tool, conditional breakpoint dialog).
* studio: Fixed bug#12037: Post condition violation at {EB_SMART_EDITOR}.refresh_line_number_display
* studio: Fixed bug#12013: View | Toolbars indicates wrong state for hidden toolbars
* studio: Fixed bug#12102: Search tool Options section cut off and mostly not visible
* pref: fixed bug#12183: Filter in preferences window is case-sensitive but should not be
* pref: fixed bug#12184 : Changing value of boolean preference when filter in effect causes crash
* debugger: Fixed bug#12195: Trying to save exception dialog when in Force Debugger mode causes crash
* debugger: Fixed bug#12194: Copying call stack to clipboard in Force Debugger mode causes crash
* debugger: Fixed bug#12265 : Ctrl+Alt+W used by the Debug - Show object viewer tool
* debugger: Fixed bug#12267: Multiple problems with Object Browser window (except for the width of the "Select Viewer" button, it seems a vision2 issue)
* debugger: Fixed bug#12283: Confirmation improvement and wrong preference category
* debugger: Fixed upper slice value for string display box.
* debugger: Fixed bug#12246: continue on cond breakpoint failure does not seem to work with Not Yet Called once
* debugger: Fixed bug#12170: Run to This Point doesn't stop unless hit count matches
* debugger: Fixed bug#12251: Saving exception message from debugger gives no error when permission problem
* debugger: Fixed suggestion bug#12230: Switch arguments and working directory in Debugging Options dialog
* debugger: Allow to save a file without the extension; fixed bug#12293: Estudio insists on adding ".txt" when save exception message from debugger
* debugger: Fixed issue with data associated with debugger grid line. A few internal data were not reseted when the expression's text was changed in the watch tool.
* debugger: Fixed bug#12257 : Watch expression that is constant real expression evaluates to 0
* vision2: Fixed bug#12210 where a pixmap will not be copied when assigned to a menu, and therefore you would get the same pixmap for all menu items instead of different ones.
* docking: Fixed bug#11870: Default layout for toolbar is not properly left aligned.
* docking: Fixed bug#11941: Dockable toolbars can have their handle placed so it cannot be accessed
* docking: Fixed bug#11944: Dragging tabs to re-order is not stable
* docking: Fixed bug#11829 CTRL+TAB selector item spacing/clipping
* docking: Fixed bug#11962: Postcondition violation in `make' of SD_NOTEBOOK_HIDE_TAB_DIALOG
* docking: Fixed bug#11970 Please add a tooltip to the Editor's class name tab
* docking: Fixed bug#11974: Address Toolbar customisations are lost
* docking: Fixed bug#12031: Another Internal Error on typing Ctrl+Tab
* docking: Fixed bug#12078: Internal Error halting debugger
* docking: Fixed bug#12090: Minor problems with resizing undocked windows
* docking: Fixed bug#12307: Window below editor doesn't return to original size after running application.(same as bug#12312)
* docking: Fixed bug#12091: Clicking "X" to close Editor tab often has no effect
* docking: Fixed bug#12117: Auto hiding tools then stepping to start debugger crashes estudio
* docking: Fixed Eiffel Studio on Linux hanging after just started undock a Window which is caused by a previous bug fixing.

===Developer changes===
* configuration: Changed STRING_PROPERTY and STRING_CHOICE_PROPERTY to drop the generic parameter and use a value of STRING_32 all the time.

==6.0.6.7183 (March 11th 2007)==
===New features===
* studio: {{Red| Added ability to configure shortcuts}}
* studio: {{Red|Auto-completion after bracketed expression. i.e. arr [i].*}}
* studio: Set editors’ description and details in Ctrl + Tab dialog.
* studio: When no class are edited, dropping a class or feature stone in the empty grey box of the editors will open a new editor related with the stone
* compiler: {{Red|Supported reattachment of generic derivations with expanded parameters to generic derivations with reference parameters on .NET.}}
* compiler: {{Red|Added option for full class checking. It can be enabled at the system, cluster or class level. However not all our code has been compiled with this option so don't be surprised if you get errors in our libraries.}} The next release should fix all the remaining issues.
* compiler: {{Red|Added [[Compilation Without Configuration]] for simple projects.}}
* docking: {{Red | Implemented lock toolbars and lock tools docking mechanism feature, and added related two new menu items under View menu.}}
* docking: Draw an extra floating title bar baseline to make it beautiful.

===Bug fixes===
* studio: Fixed a bug that Ctrl + f4 didn't close debugger tools (call stack, object, watch and thread)
* studio: Fixed bug#12216 that %B from editing text was taken as an instruction.
* studio: Fixed bug#12208 of search report display issue. Improved its mouse/keyboard behaviors and interface a little bit.
* studio: Fixed bug#12202 that linked tools did not update when auto hiding.
* studio: Fixed bug#12185: Crash with old docking layout files
* studio: Fixed bug#12212: Refactoring menu is missing
* docking: Fixed bug#12164: Large Fonts not respected in all widgets
* docking: Fixed bug#12158: Text labels disappear on panes docked to the side
* docking: Fixed bug#12197: issue with maximized editor
* docking: Fixed bug#12189: Undocked window comes back very small when shown again.
* docking: Fixed bug#12228: Breakpoints window toolbar truncated
* docking: Fixed bug#12225: Windows key messes docking indicators.
* docking: Made double click to maximize feature works fine on Linux.

==6.0.6.7079 (March 5th 2007)==
===Bug fixes===
* studio: Fixed issues with the way we launched '''finish_freezing.exe''' on Windows, we were not protecting the path to the executable against white spaces.
* debugger: Fixed issue which would prevent debugging if ISE_EIFFEL has spaces in it.
* install: Fixed incorrect shortcuts on Windows.

==6.0.6.7057 (March 3rd 2007)==
===New features===
* compiler: we are now using FreeELKS as a replacement for EiffelBase
* estudio: Made Window Eiffel Studio splash screen beautiful.

===Bug fixes===
* install: (Windows) fixed fatal error bug#12146 when attempting to browse for a folder.
* install: (Windows) fixed radio button background color different as best possible given the limitations of MSI.
* install: (Windows) pressing Back on the installed when on the Precompilation Choice page goes to the correct parent page instead of the Configure C/C++ Compiler page.
* compiler: Fix bug in .NET resx => resource generation by the compiler when using resx files with relative paths.
* compiler: Adapted the compiler so that ISE_EIFFEL does not need to be defined with a short path name on Windows, since some file systems can disable support for short path
names.
* studio: various bug fixes with the docking.
* vision2: Fixed issue where hiding a widget in an EV_FIXED and changing its position would not be reflected when showing the widget later.
* base: {{Red| Fixed issue with LINKED_QUEUE.twin which would violate its invariant.}}
* base: {{Red| Revisited contracts of LINEAR_ITERATOR.}}
* docking: bug#11981: Cannot put window from another application in front of undocked window
* estudio: bug#12076: Refresh issue on Start/Continue button
* docking: bug#12096: Sliding panel tools cause an unsightly redraw when revealed when on the right side on gtk
* docking: bug#12098: Disable text in docking toolbar on linux doesn't look disabled
* docking: bug#12099: Particular docking layout crashes estudio on exit
* docking: bug#12111: Toolbars disappear after running debugger
* docking: bug#12067: Estudio crash in {SD_TAB_STATE}.make called from move_to_zone_internal
* docking: bug#12126: Maximizing tool then closing it closes other tools and makes them unavailable
* docking: bug#12132: Estudio doesn't restore normal/debug layouts within same session
* docking: bug#12138: Sequence of saving, opening and resetting tools layout causes crash
* docking: bug#11984: Text on many buttons in estudio main window cut off at bottom
* vision2: bug#11989: Unintuitive behavior when trying to move an undocked window
* vision2: bug#12071: Auto Hide of window before pick ends hangs estudio, then F7 crashes it
* vision2: bug#12143: Window titles in title bar not visible when window has focus

===User changes===
* install: (Windows) removed information, on the welcome page, about setting up a C/C++ compiler if a compiler is detected.
* estudio: Improved background color of Linux editor place holder zone.

===Developer changes===
* docking: Added proprogate accelerator in SD_DOCKING_MANAGER.
* docking: Added SD_CONTENT.update_mini_tool_bar_size.

==6.0.6.6895 (February 25th 2007)==
===New features===
* Added the feature requested at bug#12046 that Ctrl+F3 searches current word if no text is selected.
* Internationalized choices in interface.development_window.ctrl_right_click_receiver and tools.search_tool.init_scope.
* debugger: Added "rescue" indicator in call stack tool's grid.
* debugger: {{Red|Added the possibility to evaluate an instruction with the debugger (i.e: procedure call).}}
* compiler: {{Red|Support for FreeELKS as a replacement for EiffelBase}}.
* studio: Now we can exit directly from debugging mode, no changing to normal mode needed.
* docking: SD_TOOL_BAR_CONTENT has new feature "unique_title" for store data, and using feature "title" for display.
* install: (Windows) Installer detects and configures a resident VC/VC++ compiler and provides/hides options based on what it found.
* install: (Windows) Precompilation is disabled if a VC/VC++ could not be configured to prevent creation of bad precompiled libraries.
* install: (Windows) x64 version no longer displays the option for installing the Borland C compiler because it's for x86 compilations only.
* install: (Windows) In the event of no C/C++ compiler found help is now link-provided to obtain a the free Windows SDK.
* install: (Windows) new installers with compact look and feel and better auto-configuration.

===Bug fixes===
* studio: Fixed bug#5437 that Shift+End selects too much text.
* studio: Fixed the bug that menu commands like Cut, Copy, Paste and Select All and sub commands of "Search" didn't work consistently as their shortcuts did. i.e. "Select All" always selected texts in main editor, but Ctrl+A did correct thing that was select all texts in the editor where focus was.
* studio: Fixed a bug that when dropping a stone to the editor, confirmation on saving a read only class didn't prevent the stone from loading, which means that the modified class got lost in this case.
* studio: Fixed bug#12050 that EiffelStudio crashed when trying to save a file that you didn't have write access to. Open a Save As dialog if .swp file is not creatable.
* studio: Fixed bug#12053 that Toggle Line Numbers and Go to didn't show correct sensitivity.
* studio: Fixed bug#12029 that es crashed when reopening ES with general.locale changed from English to Chinese.
* studio: Fixed bug#12061 that synchronization button not showing the proper tool. Now we try to synchronize the feature displayed in the combo box. (We only synchronized the stone.)
* studio: Fixed a crash when updating viewpoints.
* studio: Fixed bug#12068 and bug#12069, crashes when there was no editor.
* debugger: fixed issue with native_array unable to be resized with slices tool. (dotnet debugger)
* compiler: Fixed bug#11936 where namespace names included the cluster name when a cluster defined a namespace.
* studio: Fixed bug#11987 that Closing Class tab crashes estudio after move to Clusters
* studio: Fixed bug#12054 that Crash when select Editor window after exiting debugger
* studio: Fixed bug#12000 that Particular docking layout causes estudio to crash at startup
* studio: Fixed bug#11998 that Wrong tooltips on many Project tool bar buttons - say Show/Hide
* studio: Fixed bug#11873 Breakpoint tool content not refreshed when switching to debug mode
* docking: Fixed bug#11960 Alignment issues
* studio: Set docking window title bar height, tool bar height a little bit bigger for Linux specially.
* docking: Make hide tab indicator correct and tool bar drawing style correct for Linux implementation.
* studio: Fixed bug that hidden tab dialog position not correct on Linux.
* studio: Fixed bug that minimum height of docking (not tabbed) editor not correct on Linux.
* docking: Fixed bug that select a tab from hidden item drop down menu, SD_CONTENT.focus_in_actions not been called.
* docking: Fixed bug that close button of editor tab position not correct if not enough space.
* docking: Fixed bug that close button of editor tab state not updated correctly sometimes.

===User changes===
* debugger: the call stack tool now display a special icon when on feature with rescue cause.
* studio: Changed shortcut for Cluster tool to Ctrl+Alt+U.
* studio: Fixed bug#11998: Wrong tooltips on many Project tool bar buttons - say Show/Hide
* studio: Fixed bug#12048: Please improve the Debug | Tools menu
===Developer changes===
* studio: Improved the way of saving context session data. We save ids of the feature/class targeted in tools.

==6.0.6.6595 (February 11th 2007)==
===New features===
* compiler: (windows) finish_freezing.exe now looks for the installed Windows SDK recently released from Microsoft. If installed, there is no need to perform any manual C-compiler configuration.
* studio: Dependency tool tab receives stones.
* build: {{Red|Code generation will includes the facility of closing the application when last window is closed.}}

===Bug fixes===
* studio: Fixed bug#12016 where EiffelStudio would crash when trying to debug an application after cancelling a finalization.
* debugger: fixed "restart" feature which was broken in last release.
* debugger: fixed "DEBUG_OUTPUT" processing in debugger for dotnet system.
* debugger: fixed issue with "do not close ecdbgd" when the user decides to reuse the same "ecdbgd" process, be sure to reuse it.
* debugger: fixed bug#11928 and more general issue with exception on framework .NET 3
* studio: Fixed bug#11969 that diagram tool did not link to the editor (Neither dependency tool).
* studio: Fixed bug#12003 that Pick and drop of a parent class in the feature tool targeted to class view instead of showing ancestor.
* studio: Fixed bug#12018 that changing shortcut preference of external commands crashed es.
* studio: Improved history behaviors mostly according to [[History behavior]] except the preference.
* studio: Fixed a crash that opening ES with a group opened last time closing.
* studio: Fixed the bug#11959 that after refactoring a class with file name changed was not correctly reloaded.
* studio: Fixed bug#12002: Boolean Preferences cannot be edited via the keyboard
* studio: Fixed bug#12006: Shortcut Preferences cannot be edited via the keyboard
* studio: Fixed bug#11827: Extra padding on right for "Customize" toolbar menu
* studio: Fixed bug#12005: Moving tabs around issue with metric
* studio: Fixed bug#11814: Persistent redraw issue
* studio: Fixed the bug that first time tool bar floating, the width is not correct.
* studio: Fixed bug that favorite tool only can show in normal mode or debug mode.
* build: Fixed crash when generating code which included a combo box in read-only mode.

===User changes===
* studio: Changed shortcut of showing Diagram tool to Ctrl+Alt+I.
* debugger: add possibility to continue on conditional breakpoint evaluation failure
* debugger: Get rid of useless "Attributes" row in debugger's objects grids (This makes display less lighter).
* debugger: now the "Once routines" also show states of "once procedures" and not only "once functions".

===Developer changes===
* studio: Now we store in session data class/group IDs from EB_SHARED_ID_SOLUTION instead of class 'file_name's or group names which could cause a problem that moving a project lead to class missing and a problem wrong group returned (many groups with the same name).
* studio: Made fake editors for clusters if hidden when opening.

==6.0.6.6451 (February 4th 2007)==
===New features===
* debugger: now it is possible to force the environment to stay in debugger mode.
===Bug fixes===
* runtime: {{Red|Fixed a memory corruption which could occur when performing a deep_twin on an object whose graph contains a TUPLE object. See test#tuple006.}}
* runtime: {{Red|Fixed issue when retrieving 64-bit storables on 32-bit machines. It requires a regeneration of the 64-bit storables if one wants to retrieve them on 32-bit machines. Fixed bug#11744.}}
* studio: Fixed bug#11848 and bug#11939 related to the `Debugging Options' dialog which could randomly crash (related to test#tuple006 issue).
* studio: Fixed `on_text_fully_loaded' crash (bug#11943, bug#11938 and bug#11937).
* EiffelStore: Fixed ODBC on Linux.
* debugger: SPECIAL[SPECIAL[..]] is fully supported now by the debugger.
* studio: Fixed bug#11761, bug#11865 and bug#11866, general.locale didn't initialize properly. "Unselected" entry was added.
* studio: Corrected current output codepage/charset for command line ES.

==6.0.6.6309 (January 27th 2007)==
===New features===
* studio: Finished internationalizing starting dialog, wizards.
* studio: {{red|Integrated Smart Docking library.}}
* studio: {{red|Integrated tab editor mechanism.}}
* studio: Added preference "Maximum processor usage" to dictate the maximum number of processors/cores to use when compile c-code.
* EiffelWizard: Introduced i18n library to make it possible to display in different languages.
* compiler: .NET Enums are can be automatically converted to INTEGERs
* compiler: indexing tags ''interface_metadata'' and ''class_metadata'' are supported on feature level like this is done on class level and allow to specify custom attributes for associated methods only in interface type or only in implementation type.
* compiler: Static access on external routines is allowed even if not marked frozen (this simply applies a relaxed rule that was adopted by ECMA).
* debugger: dropping feature or class stones on breakpoints tool to add related breakpoint
* debugger: enhanced breakpoint mechanism by adding print message, hit count (condition), and provide "Is True" and "Has Changed" condition.
* studio: Integrated encoding library and internationalized part of batch compiler.
* base: Added facilities to read/write REAL_32 and REAL_64 values in big and little endian format in MANAGED_POINTER
* net: {{red|Updated reading routines of EiffelNet so that for all basic types they would read all the required bytes, not just stop after the first reading. This is important as in some very bad network situation or if you have some signals you could mess up the reading by only reading half of the expected bytes.}}

===Bug fixes===
* studio: Fixed bug#11760 that replacing on empty result crashed es.
* studio: Auto-complete members for open target agents have been corrected. bug#11767.
* studio: Fixed bug#11772 that a crash occurred while renaming clusters in property tool.
* compiler: Fixed bug causing test#dotnet046 to fail, now functions that are .NET properties can be called and executed from client code.

===User changes===
* studio: Added new docking feedback indicators.
* compiler: added conversion of TYPED_POINTER to POINTER before reattachment to reference entity so that the behaviour is the same in classic and .NET modes
* compiler: All versioned COM import interfaces now have versioned interface member names based on the trailing version number of the interface name, as this meta information is not available in any other way. This greatly improves the versioned names and makes implementing interfaces much easier.
* compiler: The unique keyword will yield a syntax warning if enabled.
* debugger: improved cosmetic of debugger's exception handling dialog
* base: Changed INTERNAL so that it does not have the `is_pre_ecma_mapping_disabled' attribute. If you were setting it to True, you should instead create an instance of ECMA_INTERNAL (fixes bug#11792).

===Developer changes===
*debugger: refactored breakpoints and exceptions processing for easier integration of other projects on debugger.
*compiler: updated compiler to compile FreeELKS library, however it cannot yet be executed.

==6.0.65740 (December 25th 2006)==
===New features===
* debugger: console based debugger is now working for classic, dotnet, on windows and unices (-debug or via -loop : still experimental)

===Feature removed===
===Bug fixes===
* compiler: fixed a bug in .NET consumer that can cause some assemblies to be consume infinitely.
* compiler: fixed a .NET bug that prevents System.Windows.Forms.Panel from being compiled correct and subsequently causing a compilation to fail, due to incorrect an mapped inherit property and assigner. This addresses test#dotnet043.
* compiler: Fixed bug#11758 for eweasel test#incr279, where the compiler would crash when generating the call to '''Precursor''' when both the current class and the parent class had their number of formal generics changed.
* compiler: Fixed bug#11766 for eweasel test#term146 and test#incr129 where the compiler would crash at degree 4 when checking the conformance of a feature, and the signature involves a type which have an incorrect parent hierarchy (i.e. one parent does not have the right number of actual generic parameters).
* store: {{Red| Fixed bug#10523: if you create a DB_REPOSITORY before being connected to the database, some of the queries made on the database are not returning the proper result in ODBC(e.g. odbc_sensitive_mixed will return 0 instead of 3 for an ORACLE database). By adding the precondition we nicely solve the problem by forcing client to connect first before creating an instance of DB_REPOSITORY.}}
* store: {{Red| Fixed some issues related to the new implementation of expanded semantics which would break some introspection part of EiffelStore.}}
* favorites: fixed bug#11745 "feature item" favorites were being lost on restarting EiffelStudio
* gui: fixed bug#11749 with debugger's grid being empty.
* debugger: fixed bug#11755: empty string with huge capacity were slow to be displayed.
* debugger: improved display of objects tool header bar. (minor)

===User changes===
* base: sped up {SPECIAL}.copy_data which was not inlined.

===Developer changes===

==6.0.65604 (December 17th 2006)==
===New features===
* compiler: improved backup mechanism so that overridden classes are copied in the library where they are defined (they were previously copied in the library where the override cluster was defined).
* studio: {{red|Integrated the internationalization library. Added a preference named "general.locale" to switch among languages. English and Chinese are available for the moment}}
* debugger: added auto expressions on watch tools
* studio: Added metric history support. Calculated metrics with their inputs can be sent into history so they can be recalculated afterwards.
* general: Revision number of EiffelStudio has changed because we reached the limit set by most OS for the revision (65535). So now it is split into revision.build, that is to say rev 65570 will read 6.5570.
* debugger: added an experimental console based debugger.

===Bug fixes===
* compiler: {{Red|Fixed issue with inline agents where if you have one and during a compilation from scratch you have a compiler error, then fixing this error and recompiling, it would crash when melting or freezing (test#incr277).}}
* compiler: Fixed issue with C compilation linking error when a generic class which have an invariant clause has its formal generics changed (test#incr278).
* compiler: Fixed C compilation error on Windows for trying to compile empties Cxxx directories (test#ccomp061).
* compiler: Fixed incorrect code generation of agents on attribute when target is open (test#exec264).
* compiler: Fixed incremental bug when an agent creation based on a feature whose signature changes for less arguments (test#incr276).
* compiler: Fixed a backup creation bug when two classes from the same cluster/library have the same original file name, the backup would only contain one or the other because we use the original file name. Now we use the original class name.

===User changes===
* base: Sped up HASH_TABLE iteration and lookup by about 8% or more.
* base: TUPLE can now compare items using reference equality (=) or object comparison (is_equal).
* vision2: Changed behavior of {EV_TITLED_WINDOW}.raise to always make sure the window is visible on screen (show if hidden, restore if minimized).
* vision2: Fixed behavior of is_show_requested and is_displayed for EV_GRID and its items so that it conforms to the widget behavior in Vision2.
* wel/vision2: {{Red|Raised compatibility bar to Windows 2000 or greater. No more support for Windows 98 or NT 4.0}}
* dotnet: {{Red|Renamed SYSTEM_ATTRIBUTE into NATIVE_ATTRIBUTE for consistency reasons.}}

===Developer changes===
* debugger: deep refactoring (reduce the number of onces, renamed and moved some debugger related data)
* studio: to help track incremental compilation bugs, we build a replay backup window that given a backup directory will go through each compilation and perform them the way it was done by the end user.

==6.0.65344 (December 3rd 2006)==
===New features===
* compiler: {{Red|A root type can now be a generic derivation.}}
* studio: {{Red|Project settings such as arguments/working directory/location are now stored in a user specific location that does not depend on the UUID of the project, but on its path.}}
* compiler: {{Red|Integers can now also be specified with binary and octal representation}}
* compiler: {{Red|Manifest characters can now also be specified with binary, octal and hexadecimal representation. Manifest characters can be specified up to 32 Bit.}}
* compiler: {{Red|Possibility for "hidden/implementation" clusters in libraries, clusters that are not accessible if the library is used (like libraries in libraries are not accessible).}}
* compiler: {{Red|Added supplier_precondition assertion level that enables to only check preconditions of trusted libraries.}}
* debugger: {{Red|New Debugging options dialog (to set the arguments and other)}}
* compiler: Don't do an expensive degree 6 when we freeze or finalize.
* compiler: Newly added clusters are recursive by default.
* studio: Favorites are now stored in the user settings.
* compiler: Warning if an environment variable has changed and opportunity to (temporarily) use the old, stored value
* compiler: Trigger a full configuration rebuild if environment variables have changed
* compiler: Added configurable (project to class-level) optimization for .NET project that will mark all classes frozen if they are not descended by another.
* studio: Add assemblies dialog shows more assembly information.
* studio: Some diagram generation for assemblies
* studio:Display documentation for .NET Framework assemblies on .NET 2.0
* studio: Display features tree for .NET classes.
* studio: Display uncompiled .NET classes.
* debugger: Now we can pass modified environment variables to the debuggee application.
* compiler: Externals (includes, objects, resources, ...) can now be relative to the ecf file by using the new replacement $ECF_CONFIG_PATH.
* compiler: UUID is not needed for non library systems. If no uuid is specified a random one will be generated. (Startup dialog may not work correct if the config has not been saved with the random generated uuid)
* debugger: New contextual menu on breakpoints tool for multiple action on class (enable first bp on all features ...)
* studio: Only expand the currently used target in the project settings.
* compiler: Changed version of configuration format to 1.1.0
* compiler: Only print warnings for unknown attributes and tags if we detect an unknown version (try to be upward compatible).
* compiler: Speed up consumer cache synchronization so working with large .NET caches or large assembly sets is much faster.
* debugger: now it is possible to restart the debuggee without unraising and raising again the debugger's interface
* debugger: now we keep the layout for each watch tool in preferences.
* compiler: Custom conditions now also take environment variables into account.
* compiler: Display unsubstitued path to cluster/assembly/library if a file/directory open error occurs.
* studio: Added a cancel button in the dialog of the automatic precompilation to cancel the precompilation.
* COM Wizard: EiffelStudio button is enabled also if the Eiffel compilation fails.
* compiler: Generate an error if a configuration file used in a precompile has structurally been changed as the precompile is not usable in this case anymore.
* base: The HASH_TABLE in base has two new possibilities to detect/prevent catcalls, they can be enabled by enabling assertion checking and enabling the debug clauses prevent_hash_table_catcall and detect_hash_table_catcall.
* studio: {{Red|Added dependency view so supplier/client dependency of a group/folder/class can be investigated. Feature calls are included in dependency view.}}
* studio: Added syntactical supplier/client support in class view.

===Bug fixes===
* COM wizard: {{Red|Time library was not included which lead to problems if a COM component used the DATE_TIME data type.}}
* compiler: {{Red|Fixed incrementality bug with agents where finalizing and then freezing would cause some unresolved externals.}}
* compiler: Don't do an expensive degree 6 if assertion level or similar project settings have changed.
* studio: Decreased amount of created GDI objects on windows in some grids.
* studio: Fixed a problem with externals in the project settings.
* studio: Fixed viewpoint handling for assemblies
* studio: Fixed output to file redirection in the process library on windows.
* studio: Fixed samples that would not compile.
* compiler: Fixed a crash if a library without an UUID is used.
* compiler: Fixed a problem that classes that were not visible before did not get compiled when they were made visible.
* compiler: Fixed CECIL name if there is a renaming specified in the visible clause.
* compiler: Fixed VTCT error was not detected if a prefix/renaming changed on an assembly or library.
* vision2: Fixed bug when setting a pixmap on a menu entry which has a submenu, the submenu would disappear.
* compiler: Fixed a bug in the check if local assemblies are present.
* compiler: Fixed some problems with sub clusters of overrides.
* compiler: Interpolate environment variables also in metadata cache path specified on the command line.
* compiler: Fixed some bugs in the documentation generation related to sub clusters.
* compiler: Option changes always led to an expensive degree 6 even if a fast degree 6 would have been enough.

===User changes===
* base: {{Red|EXECUTION_ENVIRONMENT.get will only retrieve environment variable. It won't retrieve a value from the registry key on Windows (from HKLM\Software\ISE\Eiffelxx\app_name). This also means that MELT_PATH on Windows cannot be set in registry; this is not really a problem since now you do not need to set it since the W_code knows where to find it.}}

===Developer changes===
* cli_debugger is now under framework, and the corresponding clib has to be compiled.
* New delivery scripts on unix will now compress packages using bzip2 as they are about 30% smaller than the packages build with gzip.
* The eifinit/studio folder has now been moved into studio/eifinit
* build has been renamed into esbuilder
* vision2_tour has been renamed into vision2_demo
* Possibility to build a delivery which fits into the unix directory layout.
* Use the normal HASH_TABLE in the compiler.
* ID_AS does no longer inherit from STRING, instead it has a name_id and the string is stored in NAMES_HEAP
* Added additional applicable inspect-able types to VOMB1 error help text.
===Road map to ISO Eiffel===
[[Language_road_map|(Under construction)]]

EiffelStudio 6.0 Releases

2007-04-16T17:19:28Z

Seilerm:

[[Category:Releases]]__NOTOC__{{ReleaseHistoryHeader}}

= EiffelStudio 6.0.x Releases=

==6.0.x==
Placeholder for new stuff since last intermediate release.
===New features===
* estudio: {{Red|Replaced all native tool bars (EV_TOOL_BAR) with Smart Docking library tool bars (SD_TOOL_BAR).}}

===Feature removed===
===Bug fixes===
* docking: Fixed bug#12389: "Reset tools layout" in debug mode does not do what I am expecting
===User changes===
===Developer changes===

==6.0.6.7849 (April 15th 2007)==
===New features===
* compiler: The notion of creation readiness according to ECMA Eiffel standard (2nd edition, chapter 8.12.12) is implemented.
===Feature removed===
===Bug fixes===
* compiler: Fixed bug#12464: If a generic derivation in a deferred class uses `like Current' as generic parameter the creation constraints are not enforced on that particular formal.
* debugger: Completed implementation for dotnet system: bug#12435: Evaluating an expression still checks for invariant.
* debugger: Fixed bug#12435: Evaluating an expression still checks for invariant
* debugger: Now it is possible to disable/restore assertion checking during debugging in classic AND dotnet system.
* debugger: Fixed bug#12461: "Run Workbench" fails if no environment variable had been added.
* debugger: Fixed bug#12442: Selecting Debug/Exception handling for uncompiled project causes crash
* debugger: Fixed bug#12443: Run Workbench button in Debugging Options window does not work when app melted
* studio: Improved memory management.

===User changes===
===Developer changes===

==6.0.6.7775 (April 9th 2007)==
===New feature===
* vision2: ability to save an EV_PIXEL_BUFFER or to convert it to EV_PIXMAP.
* wel: {{Red|Added ability to convert image formats among all image formats on Windows (using WEL_GDIP_BITMAP).}}

===Bug fixes===
* debugger: Fixed bug#12435: Evaluating an expression still checks for invariant (classic only)
* debugger: Fixed bug#12443: Run Workbench button in Debugging Options window does not work when app melted
* vision2: Fixed bug bug#12113: I'd like to be able to save an EV_PIXEL_BUFFER into a file
* estudio: Fixed bug bug#12437: Previous docking layout are not valid

===Developer changes===
* Set .NET namespaces on all ISE libraries to be as terse and coherent as possible.
* .NET precompiled libraries binary names have been changed to fit present naming for .NET assemblies.

==6.0.6.7670 (April 1st 2007)==
===New features===
* studio: {{Red|Added ability to add new classes/clusters/assemblies early on in the compilation phase instead of waiting for a successful compilation.}}

===Bug fixes===
* dotnet: {{Red|Implemented suggestion from [[.NET_Namespace_Generation]].}}
* dotnet: Fixed bug#12433 where editing a class in EiffelStudio would change its generated namespace and thus invalidating the generated assembly (recompilation from scratch was necessary).
* Vision2: {{Red|Made sure that Windows and Unix behave the same way regarding widget navigation when one has set the ''default_key_processing_handler''. The behavior is that if it is set, then the tab processing will be disabled if it returns True.}}
*debugger: Fixed (again) bug#12371: Feature Relation window not scrolled to current line in debugger
*debugger: Implemented suggestion bug#12395 :No splitter by default
*debugger: Added start workbench and finalized system on Debugging option dialogs
*debugger: Fixed bug#11688: Compiling all classes under .NET with EXE generation hangs debugger
*estudio: Fixed bug#12203: Open Layout window disappears first time View/Open Layout is selected
*estudio: Fixed bug#12164: Large Fonts not respected in all widgets
*estudio: Fixed bug#12121: Wrong cursor if undock window operation in progress when compile ends
*estudio: Fixed bug#12036: Enter on a category in the Features tool does not focus the Editor
*estudio: Fixed bug#12104: Docked tracking preference ignored
*estudio: Fixed bug#12134: Auto Hide button should have different tooltips for enable/disable
*estudio: Fixed bug#12327: Closing Editor tab makes Clickable, Flat etc buttons insensitive
*docking: Fixed bug#12103: Estudio doesn't remember layout correctly if force debugger mode or maximize a tool
*docking: Fixed bug#12241: Hiding Address tool bar and reshowing it causes it to appear on Project tool bar row
*docking: Fixed bug#12260: Hiding toolbars leaves vacant space at bottom
*docking: Fixed bug#12114: Bringing up undocked window via View/Tools unmaximizes other too

===User changes===

===Developer changes===
*visioon2: Added new class EV_BEEP which can make system default beeps.

==6.0.6.7522 (March 25th 2007)==
===New features===
* studio: Add assembly dialog assembly entires are now placed in columns. Added columns for the assembly path and processor architecture.
* studio: {{Red| Added support for multi constraint code completion.}}

===Bug fixes===
* debugger: Fixed bug#11558 about evaluation of expressions involving NATURAL_XY values
* installer: (Windows) Fixed bitmap scaling issue for large fonts.
* Fixed the problem that Precursor {CLASS}.* only showed once routines.
* Fixed the problem that Result [i].* didn't work.
* Fixed the problem that Precursor {NEW_CLASS_3} [1].* didn't work.
* Fixed the problem that {INTEGER}.max_value.* didn't work.
* Fixed bug#12323 changing class name and then canceling Class Rename crashes estudio.
* Fixed bug#12331 Windows window showed two windows instead of one after exit and restart.
* Fixed bug#12347 that deleting a class displayed in an editor tab caused crash.
* Fixed a bug that initial dropping a cluster to diagram tool did nothing.
* Fixed bug#12299 that compiling lost diagram tool when targeted to a cluster.
* Fixed bug#12355 that selecting homonyms format for feature caused crash.
* Fixed the bug that shortcut for an initial or edited external command did not work.
* Fixed bug#11879 that show all docking indicators preference only respected when setting it.
* Fixed bug#12324 that main window resizes after loading project.
* Fixed bug#12118 that closing auto hidden tools during debugging leads to estudio crash.
* Fixed bug#12120 that particular docking layout causes crash in {SD_STATE_VOID}.move_to_docking_zone.
* Fixed bug#12339 that crash when rearranging editor tabs using mouse.
* Fixed bug#12235 that toolbar text blurs when exposed on linux.
* Fixed Eiffel Studio starting flicker problem, there is only 1 time flicker during the whole Eiffel Studio starting process now.

==6.0.6.7358 (March 18th 2007)==
===New features===
* studio: Added configurable shortcuts for history back and forth.
* studio: Added ability to remember show/hide formatting marks status.
* studio: Made Eiffel Studio can open into debug mode directly.
* studio: Disable fading effects for Eiffel Studio splash screen and disabled auto hide animations on remote desktop.
* debugger: new object viewer tool. (to replace the pretty or expanded display dialog)
* compiler: {{Red|Added support for multiple constraints in formal generic parameters.}}
* docking: Made docking library title bar drawing text position care about font size.

===Bug fixes===
* compiler: Fixed issue with incorrect labeled tuples which were not detected in signature of features (see eweasel test#tuple008).
* compiler: Fixed crash when checking an incorrect labeled tuple (e.g. TUPLE [a, a: INTEGER]) (see eweasel test#tuple009).
* studio: {{Red|Fixed bug#12083 where classes in override clusters would not get recompiled properly when automatically saved by EiffelStudio when requesting a compilation.}}
* studio: Fixed display of public key token on add assembly dialog.
* studio: Improved show/hide formatting marks command. This command only functioned on current editor and when current editor switched the name was not displayed correctly. Now it functions on all editors of current window.
* studio: Fixed bug#12256 that dependency tool could not close.
* studio: Fixed bug#12261 that find was broken, and added Home/End actions to the report grid.
* studio: Fixed bug#12264 that first column of preference grid was too narrow.
* studio: Fixed a bug that Alt+Left/Alt+Right didn't function on diagram tool and dependency tool.
* studio: Fixed a bug that address history forth command was always disabled in diagram tool.
* studio: Fixed bug#12258 that completion window was brought up by dot after a number.
* studio: Fixed the bug that shortcut for class completion triggered feature completion window in completable text fields (i.e. Watch tool, conditional breakpoint dialog).
* studio: Fixed bug#12037: Post condition violation at {EB_SMART_EDITOR}.refresh_line_number_display
* studio: Fixed bug#12013: View | Toolbars indicates wrong state for hidden toolbars
* studio: Fixed bug#12102: Search tool Options section cut off and mostly not visible
* pref: fixed bug#12183: Filter in preferences window is case-sensitive but should not be
* pref: fixed bug#12184 : Changing value of boolean preference when filter in effect causes crash
* debugger: Fixed bug#12195: Trying to save exception dialog when in Force Debugger mode causes crash
* debugger: Fixed bug#12194: Copying call stack to clipboard in Force Debugger mode causes crash
* debugger: Fixed bug#12265 : Ctrl+Alt+W used by the Debug - Show object viewer tool
* debugger: Fixed bug#12267: Multiple problems with Object Browser window (except for the width of the "Select Viewer" button, it seems a vision2 issue)
* debugger: Fixed bug#12283: Confirmation improvement and wrong preference category
* debugger: Fixed upper slice value for string display box.
* debugger: Fixed bug#12246: continue on cond breakpoint failure does not seem to work with Not Yet Called once
* debugger: Fixed bug#12170: Run to This Point doesn't stop unless hit count matches
* debugger: Fixed bug#12251: Saving exception message from debugger gives no error when permission problem
* debugger: Fixed suggestion bug#12230: Switch arguments and working directory in Debugging Options dialog
* debugger: Allow to save a file without the extension; fixed bug#12293: Estudio insists on adding ".txt" when save exception message from debugger
* debugger: Fixed issue with data associated with debugger grid line. A few internal data were not reseted when the expression's text was changed in the watch tool.
* debugger: Fixed bug#12257 : Watch expression that is constant real expression evaluates to 0
* vision2: Fixed bug#12210 where a pixmap will not be copied when assigned to a menu, and therefore you would get the same pixmap for all menu items instead of different ones.
* docking: Fixed bug#11870: Default layout for toolbar is not properly left aligned.
* docking: Fixed bug#11941: Dockable toolbars can have their handle placed so it cannot be accessed
* docking: Fixed bug#11944: Dragging tabs to re-order is not stable
* docking: Fixed bug#11829 CTRL+TAB selector item spacing/clipping
* docking: Fixed bug#11962: Postcondition violation in `make' of SD_NOTEBOOK_HIDE_TAB_DIALOG
* docking: Fixed bug#11970 Please add a tooltip to the Editor's class name tab
* docking: Fixed bug#11974: Address Toolbar customisations are lost
* docking: Fixed bug#12031: Another Internal Error on typing Ctrl+Tab
* docking: Fixed bug#12078: Internal Error halting debugger
* docking: Fixed bug#12090: Minor problems with resizing undocked windows
* docking: Fixed bug#12307: Window below editor doesn't return to original size after running application.(same as bug#12312)
* docking: Fixed bug#12091: Clicking "X" to close Editor tab often has no effect
* docking: Fixed bug#12117: Auto hiding tools then stepping to start debugger crashes estudio
* docking: Fixed Eiffel Studio on Linux hanging after just started undock a Window which is caused by a previous bug fixing.

===Developer changes===
* configuration: Changed STRING_PROPERTY and STRING_CHOICE_PROPERTY to drop the generic parameter and use a value of STRING_32 all the time.

==6.0.6.7183 (March 11th 2007)==
===New features===
* studio: {{Red| Added ability to configure shortcuts}}
* studio: {{Red|Auto-completion after bracketed expression. i.e. arr [i].*}}
* studio: Set editors’ description and details in Ctrl + Tab dialog.
* studio: When no class are edited, dropping a class or feature stone in the empty grey box of the editors will open a new editor related with the stone
* compiler: {{Red|Supported reattachment of generic derivations with expanded parameters to generic derivations with reference parameters on .NET.}}
* compiler: {{Red|Added option for full class checking. It can be enabled at the system, cluster or class level. However not all our code has been compiled with this option so don't be surprised if you get errors in our libraries.}} The next release should fix all the remaining issues.
* compiler: {{Red|Added [[Compilation Without Configuration]] for simple projects.}}
* docking: {{Red | Implemented lock toolbars and lock tools docking mechanism feature, and added related two new menu items under View menu.}}
* docking: Draw an extra floating title bar baseline to make it beautiful.

===Bug fixes===
* studio: Fixed a bug that Ctrl + f4 didn't close debugger tools (call stack, object, watch and thread)
* studio: Fixed bug#12216 that %B from editing text was taken as an instruction.
* studio: Fixed bug#12208 of search report display issue. Improved its mouse/keyboard behaviors and interface a little bit.
* studio: Fixed bug#12202 that linked tools did not update when auto hiding.
* studio: Fixed bug#12185: Crash with old docking layout files
* studio: Fixed bug#12212: Refactoring menu is missing
* docking: Fixed bug#12164: Large Fonts not respected in all widgets
* docking: Fixed bug#12158: Text labels disappear on panes docked to the side
* docking: Fixed bug#12197: issue with maximized editor
* docking: Fixed bug#12189: Undocked window comes back very small when shown again.
* docking: Fixed bug#12228: Breakpoints window toolbar truncated
* docking: Fixed bug#12225: Windows key messes docking indicators.
* docking: Made double click to maximize feature works fine on Linux.

==6.0.6.7079 (March 5th 2007)==
===Bug fixes===
* studio: Fixed issues with the way we launched '''finish_freezing.exe''' on Windows, we were not protecting the path to the executable against white spaces.
* debugger: Fixed issue which would prevent debugging if ISE_EIFFEL has spaces in it.
* install: Fixed incorrect shortcuts on Windows.

==6.0.6.7057 (March 3rd 2007)==
===New features===
* compiler: we are now using FreeELKS as a replacement for EiffelBase
* estudio: Made Window Eiffel Studio splash screen beautiful.

===Bug fixes===
* install: (Windows) fixed fatal error bug#12146 when attempting to browse for a folder.
* install: (Windows) fixed radio button background color different as best possible given the limitations of MSI.
* install: (Windows) pressing Back on the installed when on the Precompilation Choice page goes to the correct parent page instead of the Configure C/C++ Compiler page.
* compiler: Fix bug in .NET resx => resource generation by the compiler when using resx files with relative paths.
* compiler: Adapted the compiler so that ISE_EIFFEL does not need to be defined with a short path name on Windows, since some file systems can disable support for short path
names.
* studio: various bug fixes with the docking.
* vision2: Fixed issue where hiding a widget in an EV_FIXED and changing its position would not be reflected when showing the widget later.
* base: {{Red| Fixed issue with LINKED_QUEUE.twin which would violate its invariant.}}
* base: {{Red| Revisited contracts of LINEAR_ITERATOR.}}
* docking: bug#11981: Cannot put window from another application in front of undocked window
* estudio: bug#12076: Refresh issue on Start/Continue button
* docking: bug#12096: Sliding panel tools cause an unsightly redraw when revealed when on the right side on gtk
* docking: bug#12098: Disable text in docking toolbar on linux doesn't look disabled
* docking: bug#12099: Particular docking layout crashes estudio on exit
* docking: bug#12111: Toolbars disappear after running debugger
* docking: bug#12067: Estudio crash in {SD_TAB_STATE}.make called from move_to_zone_internal
* docking: bug#12126: Maximizing tool then closing it closes other tools and makes them unavailable
* docking: bug#12132: Estudio doesn't restore normal/debug layouts within same session
* docking: bug#12138: Sequence of saving, opening and resetting tools layout causes crash
* docking: bug#11984: Text on many buttons in estudio main window cut off at bottom
* vision2: bug#11989: Unintuitive behavior when trying to move an undocked window
* vision2: bug#12071: Auto Hide of window before pick ends hangs estudio, then F7 crashes it
* vision2: bug#12143: Window titles in title bar not visible when window has focus

===User changes===
* install: (Windows) removed information, on the welcome page, about setting up a C/C++ compiler if a compiler is detected.
* estudio: Improved background color of Linux editor place holder zone.

===Developer changes===
* docking: Added proprogate accelerator in SD_DOCKING_MANAGER.
* docking: Added SD_CONTENT.update_mini_tool_bar_size.

==6.0.6.6895 (February 25th 2007)==
===New features===
* Added the feature requested at bug#12046 that Ctrl+F3 searches current word if no text is selected.
* Internationalized choices in interface.development_window.ctrl_right_click_receiver and tools.search_tool.init_scope.
* debugger: Added "rescue" indicator in call stack tool's grid.
* debugger: {{Red|Added the possibility to evaluate an instruction with the debugger (i.e: procedure call).}}
* compiler: {{Red|Support for FreeELKS as a replacement for EiffelBase}}.
* studio: Now we can exit directly from debugging mode, no changing to normal mode needed.
* docking: SD_TOOL_BAR_CONTENT has new feature "unique_title" for store data, and using feature "title" for display.
* install: (Windows) Installer detects and configures a resident VC/VC++ compiler and provides/hides options based on what it found.
* install: (Windows) Precompilation is disabled if a VC/VC++ could not be configured to prevent creation of bad precompiled libraries.
* install: (Windows) x64 version no longer displays the option for installing the Borland C compiler because it's for x86 compilations only.
* install: (Windows) In the event of no C/C++ compiler found help is now link-provided to obtain a the free Windows SDK.
* install: (Windows) new installers with compact look and feel and better auto-configuration.

===Bug fixes===
* studio: Fixed bug#5437 that Shift+End selects too much text.
* studio: Fixed the bug that menu commands like Cut, Copy, Paste and Select All and sub commands of "Search" didn't work consistently as their shortcuts did. i.e. "Select All" always selected texts in main editor, but Ctrl+A did correct thing that was select all texts in the editor where focus was.
* studio: Fixed a bug that when dropping a stone to the editor, confirmation on saving a read only class didn't prevent the stone from loading, which means that the modified class got lost in this case.
* studio: Fixed bug#12050 that EiffelStudio crashed when trying to save a file that you didn't have write access to. Open a Save As dialog if .swp file is not creatable.
* studio: Fixed bug#12053 that Toggle Line Numbers and Go to didn't show correct sensitivity.
* studio: Fixed bug#12029 that es crashed when reopening ES with general.locale changed from English to Chinese.
* studio: Fixed bug#12061 that synchronization button not showing the proper tool. Now we try to synchronize the feature displayed in the combo box. (We only synchronized the stone.)
* studio: Fixed a crash when updating viewpoints.
* studio: Fixed bug#12068 and bug#12069, crashes when there was no editor.
* debugger: fixed issue with native_array unable to be resized with slices tool. (dotnet debugger)
* compiler: Fixed bug#11936 where namespace names included the cluster name when a cluster defined a namespace.
* studio: Fixed bug#11987 that Closing Class tab crashes estudio after move to Clusters
* studio: Fixed bug#12054 that Crash when select Editor window after exiting debugger
* studio: Fixed bug#12000 that Particular docking layout causes estudio to crash at startup
* studio: Fixed bug#11998 that Wrong tooltips on many Project tool bar buttons - say Show/Hide
* studio: Fixed bug#11873 Breakpoint tool content not refreshed when switching to debug mode
* docking: Fixed bug#11960 Alignment issues
* studio: Set docking window title bar height, tool bar height a little bit bigger for Linux specially.
* docking: Make hide tab indicator correct and tool bar drawing style correct for Linux implementation.
* studio: Fixed bug that hidden tab dialog position not correct on Linux.
* studio: Fixed bug that minimum height of docking (not tabbed) editor not correct on Linux.
* docking: Fixed bug that select a tab from hidden item drop down menu, SD_CONTENT.focus_in_actions not been called.
* docking: Fixed bug that close button of editor tab position not correct if not enough space.
* docking: Fixed bug that close button of editor tab state not updated correctly sometimes.

===User changes===
* debugger: the call stack tool now display a special icon when on feature with rescue cause.
* studio: Changed shortcut for Cluster tool to Ctrl+Alt+U.
* studio: Fixed bug#11998: Wrong tooltips on many Project tool bar buttons - say Show/Hide
* studio: Fixed bug#12048: Please improve the Debug | Tools menu
===Developer changes===
* studio: Improved the way of saving context session data. We save ids of the feature/class targeted in tools.

==6.0.6.6595 (February 11th 2007)==
===New features===
* compiler: (windows) finish_freezing.exe now looks for the installed Windows SDK recently released from Microsoft. If installed, there is no need to perform any manual C-compiler configuration.
* studio: Dependency tool tab receives stones.
* build: {{Red|Code generation will includes the facility of closing the application when last window is closed.}}

===Bug fixes===
* studio: Fixed bug#12016 where EiffelStudio would crash when trying to debug an application after cancelling a finalization.
* debugger: fixed "restart" feature which was broken in last release.
* debugger: fixed "DEBUG_OUTPUT" processing in debugger for dotnet system.
* debugger: fixed issue with "do not close ecdbgd" when the user decides to reuse the same "ecdbgd" process, be sure to reuse it.
* debugger: fixed bug#11928 and more general issue with exception on framework .NET 3
* studio: Fixed bug#11969 that diagram tool did not link to the editor (Neither dependency tool).
* studio: Fixed bug#12003 that Pick and drop of a parent class in the feature tool targeted to class view instead of showing ancestor.
* studio: Fixed bug#12018 that changing shortcut preference of external commands crashed es.
* studio: Improved history behaviors mostly according to [[History behavior]] except the preference.
* studio: Fixed a crash that opening ES with a group opened last time closing.
* studio: Fixed the bug#11959 that after refactoring a class with file name changed was not correctly reloaded.
* studio: Fixed bug#12002: Boolean Preferences cannot be edited via the keyboard
* studio: Fixed bug#12006: Shortcut Preferences cannot be edited via the keyboard
* studio: Fixed bug#11827: Extra padding on right for "Customize" toolbar menu
* studio: Fixed bug#12005: Moving tabs around issue with metric
* studio: Fixed bug#11814: Persistent redraw issue
* studio: Fixed the bug that first time tool bar floating, the width is not correct.
* studio: Fixed bug that favorite tool only can show in normal mode or debug mode.
* build: Fixed crash when generating code which included a combo box in read-only mode.

===User changes===
* studio: Changed shortcut of showing Diagram tool to Ctrl+Alt+I.
* debugger: add possibility to continue on conditional breakpoint evaluation failure
* debugger: Get rid of useless "Attributes" row in debugger's objects grids (This makes display less lighter).
* debugger: now the "Once routines" also show states of "once procedures" and not only "once functions".

===Developer changes===
* studio: Now we store in session data class/group IDs from EB_SHARED_ID_SOLUTION instead of class 'file_name's or group names which could cause a problem that moving a project lead to class missing and a problem wrong group returned (many groups with the same name).
* studio: Made fake editors for clusters if hidden when opening.

==6.0.6.6451 (February 4th 2007)==
===New features===
* debugger: now it is possible to force the environment to stay in debugger mode.
===Bug fixes===
* runtime: {{Red|Fixed a memory corruption which could occur when performing a deep_twin on an object whose graph contains a TUPLE object. See test#tuple006.}}
* runtime: {{Red|Fixed issue when retrieving 64-bit storables on 32-bit machines. It requires a regeneration of the 64-bit storables if one wants to retrieve them on 32-bit machines. Fixed bug#11744.}}
* studio: Fixed bug#11848 and bug#11939 related to the `Debugging Options' dialog which could randomly crash (related to test#tuple006 issue).
* studio: Fixed `on_text_fully_loaded' crash (bug#11943, bug#11938 and bug#11937).
* EiffelStore: Fixed ODBC on Linux.
* debugger: SPECIAL[SPECIAL[..]] is fully supported now by the debugger.
* studio: Fixed bug#11761, bug#11865 and bug#11866, general.locale didn't initialize properly. "Unselected" entry was added.
* studio: Corrected current output codepage/charset for command line ES.

==6.0.6.6309 (January 27th 2007)==
===New features===
* studio: Finished internationalizing starting dialog, wizards.
* studio: {{red|Integrated Smart Docking library.}}
* studio: {{red|Integrated tab editor mechanism.}}
* studio: Added preference "Maximum processor usage" to dictate the maximum number of processors/cores to use when compile c-code.
* EiffelWizard: Introduced i18n library to make it possible to display in different languages.
* compiler: .NET Enums are can be automatically converted to INTEGERs
* compiler: indexing tags ''interface_metadata'' and ''class_metadata'' are supported on feature level like this is done on class level and allow to specify custom attributes for associated methods only in interface type or only in implementation type.
* compiler: Static access on external routines is allowed even if not marked frozen (this simply applies a relaxed rule that was adopted by ECMA).
* debugger: dropping feature or class stones on breakpoints tool to add related breakpoint
* debugger: enhanced breakpoint mechanism by adding print message, hit count (condition), and provide "Is True" and "Has Changed" condition.
* studio: Integrated encoding library and internationalized part of batch compiler.
* base: Added facilities to read/write REAL_32 and REAL_64 values in big and little endian format in MANAGED_POINTER
* net: {{red|Updated reading routines of EiffelNet so that for all basic types they would read all the required bytes, not just stop after the first reading. This is important as in some very bad network situation or if you have some signals you could mess up the reading by only reading half of the expected bytes.}}

===Bug fixes===
* studio: Fixed bug#11760 that replacing on empty result crashed es.
* studio: Auto-complete members for open target agents have been corrected. bug#11767.
* studio: Fixed bug#11772 that a crash occurred while renaming clusters in property tool.
* compiler: Fixed bug causing test#dotnet046 to fail, now functions that are .NET properties can be called and executed from client code.

===User changes===
* studio: Added new docking feedback indicators.
* compiler: added conversion of TYPED_POINTER to POINTER before reattachment to reference entity so that the behaviour is the same in classic and .NET modes
* compiler: All versioned COM import interfaces now have versioned interface member names based on the trailing version number of the interface name, as this meta information is not available in any other way. This greatly improves the versioned names and makes implementing interfaces much easier.
* compiler: The unique keyword will yield a syntax warning if enabled.
* debugger: improved cosmetic of debugger's exception handling dialog
* base: Changed INTERNAL so that it does not have the `is_pre_ecma_mapping_disabled' attribute. If you were setting it to True, you should instead create an instance of ECMA_INTERNAL (fixes bug#11792).

===Developer changes===
*debugger: refactored breakpoints and exceptions processing for easier integration of other projects on debugger.
*compiler: updated compiler to compile FreeELKS library, however it cannot yet be executed.

==6.0.65740 (December 25th 2006)==
===New features===
* debugger: console based debugger is now working for classic, dotnet, on windows and unices (-debug or via -loop : still experimental)

===Feature removed===
===Bug fixes===
* compiler: fixed a bug in .NET consumer that can cause some assemblies to be consume infinitely.
* compiler: fixed a .NET bug that prevents System.Windows.Forms.Panel from being compiled correct and subsequently causing a compilation to fail, due to incorrect an mapped inherit property and assigner. This addresses test#dotnet043.
* compiler: Fixed bug#11758 for eweasel test#incr279, where the compiler would crash when generating the call to '''Precursor''' when both the current class and the parent class had their number of formal generics changed.
* compiler: Fixed bug#11766 for eweasel test#term146 and test#incr129 where the compiler would crash at degree 4 when checking the conformance of a feature, and the signature involves a type which have an incorrect parent hierarchy (i.e. one parent does not have the right number of actual generic parameters).
* store: {{Red| Fixed bug#10523: if you create a DB_REPOSITORY before being connected to the database, some of the queries made on the database are not returning the proper result in ODBC(e.g. odbc_sensitive_mixed will return 0 instead of 3 for an ORACLE database). By adding the precondition we nicely solve the problem by forcing client to connect first before creating an instance of DB_REPOSITORY.}}
* store: {{Red| Fixed some issues related to the new implementation of expanded semantics which would break some introspection part of EiffelStore.}}
* favorites: fixed bug#11745 "feature item" favorites were being lost on restarting EiffelStudio
* gui: fixed bug#11749 with debugger's grid being empty.
* debugger: fixed bug#11755: empty string with huge capacity were slow to be displayed.
* debugger: improved display of objects tool header bar. (minor)

===User changes===
* base: sped up {SPECIAL}.copy_data which was not inlined.

===Developer changes===

==6.0.65604 (December 17th 2006)==
===New features===
* compiler: improved backup mechanism so that overridden classes are copied in the library where they are defined (they were previously copied in the library where the override cluster was defined).
* studio: {{red|Integrated the internationalization library. Added a preference named "general.locale" to switch among languages. English and Chinese are available for the moment}}
* debugger: added auto expressions on watch tools
* studio: Added metric history support. Calculated metrics with their inputs can be sent into history so they can be recalculated afterwards.
* general: Revision number of EiffelStudio has changed because we reached the limit set by most OS for the revision (65535). So now it is split into revision.build, that is to say rev 65570 will read 6.5570.
* debugger: added an experimental console based debugger.

===Bug fixes===
* compiler: {{Red|Fixed issue with inline agents where if you have one and during a compilation from scratch you have a compiler error, then fixing this error and recompiling, it would crash when melting or freezing (test#incr277).}}
* compiler: Fixed issue with C compilation linking error when a generic class which have an invariant clause has its formal generics changed (test#incr278).
* compiler: Fixed C compilation error on Windows for trying to compile empties Cxxx directories (test#ccomp061).
* compiler: Fixed incorrect code generation of agents on attribute when target is open (test#exec264).
* compiler: Fixed incremental bug when an agent creation based on a feature whose signature changes for less arguments (test#incr276).
* compiler: Fixed a backup creation bug when two classes from the same cluster/library have the same original file name, the backup would only contain one or the other because we use the original file name. Now we use the original class name.

===User changes===
* base: Sped up HASH_TABLE iteration and lookup by about 8% or more.
* base: TUPLE can now compare items using reference equality (=) or object comparison (is_equal).
* vision2: Changed behavior of {EV_TITLED_WINDOW}.raise to always make sure the window is visible on screen (show if hidden, restore if minimized).
* vision2: Fixed behavior of is_show_requested and is_displayed for EV_GRID and its items so that it conforms to the widget behavior in Vision2.
* wel/vision2: {{Red|Raised compatibility bar to Windows 2000 or greater. No more support for Windows 98 or NT 4.0}}
* dotnet: {{Red|Renamed SYSTEM_ATTRIBUTE into NATIVE_ATTRIBUTE for consistency reasons.}}

===Developer changes===
* debugger: deep refactoring (reduce the number of onces, renamed and moved some debugger related data)
* studio: to help track incremental compilation bugs, we build a replay backup window that given a backup directory will go through each compilation and perform them the way it was done by the end user.

==6.0.65344 (December 3rd 2006)==
===New features===
* compiler: {{Red|A root type can now be a generic derivation.}}
* studio: {{Red|Project settings such as arguments/working directory/location are now stored in a user specific location that does not depend on the UUID of the project, but on its path.}}
* compiler: {{Red|Integers can now also be specified with binary and octal representation}}
* compiler: {{Red|Manifest characters can now also be specified with binary, octal and hexadecimal representation. Manifest characters can be specified up to 32 Bit.}}
* compiler: {{Red|Possibility for "hidden/implementation" clusters in libraries, clusters that are not accessible if the library is used (like libraries in libraries are not accessible).}}
* compiler: {{Red|Added supplier_precondition assertion level that enables to only check preconditions of trusted libraries.}}
* debugger: {{Red|New Debugging options dialog (to set the arguments and other)}}
* compiler: Don't do an expensive degree 6 when we freeze or finalize.
* compiler: Newly added clusters are recursive by default.
* studio: Favorites are now stored in the user settings.
* compiler: Warning if an environment variable has changed and opportunity to (temporarily) use the old, stored value
* compiler: Trigger a full configuration rebuild if environment variables have changed
* compiler: Added configurable (project to class-level) optimization for .NET project that will mark all classes frozen if they are not descended by another.
* studio: Add assemblies dialog shows more assembly information.
* studio: Some diagram generation for assemblies
* studio:Display documentation for .NET Framework assemblies on .NET 2.0
* studio: Display features tree for .NET classes.
* studio: Display uncompiled .NET classes.
* debugger: Now we can pass modified environment variables to the debuggee application.
* compiler: Externals (includes, objects, resources, ...) can now be relative to the ecf file by using the new replacement $ECF_CONFIG_PATH.
* compiler: UUID is not needed for non library systems. If no uuid is specified a random one will be generated. (Startup dialog may not work correct if the config has not been saved with the random generated uuid)
* debugger: New contextual menu on breakpoints tool for multiple action on class (enable first bp on all features ...)
* studio: Only expand the currently used target in the project settings.
* compiler: Changed version of configuration format to 1.1.0
* compiler: Only print warnings for unknown attributes and tags if we detect an unknown version (try to be upward compatible).
* compiler: Speed up consumer cache synchronization so working with large .NET caches or large assembly sets is much faster.
* debugger: now it is possible to restart the debuggee without unraising and raising again the debugger's interface
* debugger: now we keep the layout for each watch tool in preferences.
* compiler: Custom conditions now also take environment variables into account.
* compiler: Display unsubstitued path to cluster/assembly/library if a file/directory open error occurs.
* studio: Added a cancel button in the dialog of the automatic precompilation to cancel the precompilation.
* COM Wizard: EiffelStudio button is enabled also if the Eiffel compilation fails.
* compiler: Generate an error if a configuration file used in a precompile has structurally been changed as the precompile is not usable in this case anymore.
* base: The HASH_TABLE in base has two new possibilities to detect/prevent catcalls, they can be enabled by enabling assertion checking and enabling the debug clauses prevent_hash_table_catcall and detect_hash_table_catcall.
* studio: {{Red|Added dependency view so supplier/client dependency of a group/folder/class can be investigated. Feature calls are included in dependency view.}}
* studio: Added syntactical supplier/client support in class view.

===Bug fixes===
* COM wizard: {{Red|Time library was not included which lead to problems if a COM component used the DATE_TIME data type.}}
* compiler: {{Red|Fixed incrementality bug with agents where finalizing and then freezing would cause some unresolved externals.}}
* compiler: Don't do an expensive degree 6 if assertion level or similar project settings have changed.
* studio: Decreased amount of created GDI objects on windows in some grids.
* studio: Fixed a problem with externals in the project settings.
* studio: Fixed viewpoint handling for assemblies
* studio: Fixed output to file redirection in the process library on windows.
* studio: Fixed samples that would not compile.
* compiler: Fixed a crash if a library without an UUID is used.
* compiler: Fixed a problem that classes that were not visible before did not get compiled when they were made visible.
* compiler: Fixed CECIL name if there is a renaming specified in the visible clause.
* compiler: Fixed VTCT error was not detected if a prefix/renaming changed on an assembly or library.
* vision2: Fixed bug when setting a pixmap on a menu entry which has a submenu, the submenu would disappear.
* compiler: Fixed a bug in the check if local assemblies are present.
* compiler: Fixed some problems with sub clusters of overrides.
* compiler: Interpolate environment variables also in metadata cache path specified on the command line.
* compiler: Fixed some bugs in the documentation generation related to sub clusters.
* compiler: Option changes always led to an expensive degree 6 even if a fast degree 6 would have been enough.

===User changes===
* base: {{Red|EXECUTION_ENVIRONMENT.get will only retrieve environment variable. It won't retrieve a value from the registry key on Windows (from HKLM\Software\ISE\Eiffelxx\app_name). This also means that MELT_PATH on Windows cannot be set in registry; this is not really a problem since now you do not need to set it since the W_code knows where to find it.}}

===Developer changes===
* cli_debugger is now under framework, and the corresponding clib has to be compiled.
* New delivery scripts on unix will now compress packages using bzip2 as they are about 30% smaller than the packages build with gzip.
* The eifinit/studio folder has now been moved into studio/eifinit
* build has been renamed into esbuilder
* vision2_tour has been renamed into vision2_demo
* Possibility to build a delivery which fits into the unix directory layout.
* Use the normal HASH_TABLE in the compiler.
* ID_AS does no longer inherit from STRING, instead it has a name_id and the string is stored in NAMES_HEAP
* Added additional applicable inspect-able types to VOMB1 error help text.
===Road map to ISO Eiffel===
[[Language_road_map|(Under construction)]]

Talk:Agent problems

2007-04-12T16:45:59Z

Seilerm: /* Is CAT Call */

== Is CAT Call ==

'''--[[User:Schoelle|Schoelle]] 09:26, 21 November 2006 (CET)'''

First comment: I assume you are missing a 'l_f := f'.

Second comment: this is a well known CAT call, caused by the (unsound) inheritance relation 'X[A] is subtype of X[B]' if 'A is subtype of B'.

'''--[[User:konradm|konradm]]'''

This article is in a very early state, so don't bother commenting to much on it. The intention is to list all the problems of the mechanism. Especially the fact that one has to type in a whole lot of type information for very little guarantees from the type system.

I am aware that I am not the first one to be aware of this problem. But I am not sure whether this problem is revered to as a CAT call. When it is, and when the new CAT call solution will indeed be implemented, what are the consequences? You can only make agents to features with arguments of detachable type?

--[[User:Ericb|Ericb]] 17:36, 11 April 2007 (CEST): I tried to compiled this code with Gobo's gec/gelint and I got this error:

[CATCALL] class FOO (10,14): type 'TUPLE' of actual argument #1 does not conform
to type 'TUPLE [B]' of formal argument in feature `item' in class 'FUNCTION [A,
TUPLE [B], C]'

'''--[[User:Manus|manus]] 19:41, 11 April 2007 (CEST)''' Which options did you use and which rules of ECMA is supposed to trigger this?

--[[User:Ericb|Ericb]] 23:44, 11 April 2007 (CEST): I ran gec with the default options. If I remember correctly ECMA says that either the compiler should report CAT-calls at compile time, or an exception should be raised at run-time. Gec chose the first alternative using the dynamic type set mechanism as a means to achieve that. The dynamic type set of `l_f' contains only one type: FUNCTION [A, TUPLE [B], C]. This is what I explicitly passed as argument to `foo' in the small program that I tried to compile with gec. So for that target type, the expected argument type for the call to `item' is TUPLE [B]. But what we get is an instance of TUPLE.

--[[User:Seilerm|Seilerm]] 01:55, 12 April 2007 (CEST)
Is there a plan to prevent this statically from happening?

--[[User:Ericb|Ericb]] 08:11, 12 April 2007 (CEST): gec/gelint do that statically (i.e. at compilation time).

--[[User:Seilerm|Seilerm]] 18:45, 12 April 2007 (CEST)
I was looking for more information about this. I haven't found anything on gobosoft.com (under construction so far :-). Anyway, the thing is that I thought it's not possible to do this analysis without false positives (or not reporting all CAT calls). I have this from another page which Matthias wrote ([[DynamicTypeSet]]). Is it ok if I would summarize this algorithm as stripped down program execution (not taking into account branches, etc.) which has to know the entire system?

Talk:Agent problems

Seilerm:

[[Category:ECMA]]
{{Warning|'''Warning''': Article under development}}

==Introduction==

===Example===

<e>
class T
end

class U
inherit T
-- no covariant feature redefinition
end
</e>

==Conformance==

===Type conformance===

{| class="wikitable"
|-
| conforms to
! T
! T..NONE
! ANY..T
! U
|-
! T
| true
| false
| true
| false
|-
! T..NONE
| true
| false
| true
| false
|-
! ANY..T
| false
| false
| false
| false
|-
! U
| true
| false
| true
| true
|}

===Generic conformance===

{| class="wikitable"
|-
| conforms to
! LIST [ANY]
! LIST [T]
! LIST [T..NONE]
! LIST [ANY..T]
! LIST [U]
|-
! LIST [ANY]
| true
| false
| false
| true
| false
|-
! LIST [T]
| false
| true
| true
| true
| false
|-
! LIST [T..NONE]
| false
| false
| true
| false
| false
|-
! LIST [ANY..T]
| false
| false
| false
| true
| false
|-
! LIST [U]
| false
| '''false'''
| true
| false
| true
|}

<e>
-- legal
T := LIST [T..NONE] .item
LIST [T..NONE] .put (Void)

-- illegal
U := LIST [T..NONE] .item
LIST [T..NONE] .put (T)

-- legal
LIST [ANY..T] .put (T)
LIST [ANY..T] .put (U)
ANY := LIST [ANY..T] .item

-- illegal
LIST [ANY..T] .put (ANY)
T := LIST [ANY..T] .item
</e>

== How should one understand this? ==
<e>
class PERSON
end

class STUDENT
inherit
PERSON
end

class EMPLOYEE
inherit
PERSON
end

class EMPLOYED_STUDENT
inherit
EMPLOYEE
STUDENT
end
</e>
What this actually is, is an extension to the type system. It helps you to proper derive an interface of a generic type.
For example an actual type parameter for G in <e>LIST [G]</e> is [PERSON..EMPLOYED_STUDENT].
The interface generated by this derivations is simply that the first type (PERSON) is taken wherever G occurs as a return type.
The second type EMPLOYED_STUDENT is taken wherever G occurs as an argument type.

'''The conformance rules for such new interfaces simply reflect that arguments are contra-variant and return types are covariant.'''

<e>
(generic derived) class LIST[PERSON..EMPLOYED_STUDENT]

put (v: EMPLOYED_STUDENT)

item: PERSON
</e>

That's basically all there is to say about this enhancement to the Eiffel type system.
Except that one might adapt the syntax, another idea is:
<type_for_arguments>:<type_for_return_types>
This would more resemble an actual generated signature of a feature which looks initialy like
<e>
class EXAMPLE [G]
feature
example (a_g: G): G
end
</e>

A type declaration with this syntax would look like:
<e>
local
l_example: EXAMPLE [EMLPOYED_STYDENT: STUDENT]
l_employed_student: EMPLOYED_STUDENT
l_person: PERSON
do
-- l_example.example (a_g: EMPLOYED_STUDENT): STUDENT
l_person := l_example.example (l_employed_student)
end
</e>
But let's stick with the initial syntax for now.

==Agents==

The neat thing about this extension is, that there is no need to cut down the expressiveness of the agent mechanism to make them perfectly save to use with full support for all legal situations.

Procedure class:
<e>
class PROCEDURE [BASE_TYPE, OPEN_ARGS -> TUPLE []]
-- Signature of call is generated by the compiler. To visualize this we add _reflected to the argument tuple.
call (args: OPEN_ARGS_reflected) -- valid
do end

end
</e>

==agent (T)==

Type declaration:
<e>
an_agent: PROCEDURE [ANY..NONE, TUPLE..TUPLE [ANY..T]] --> like agent (T)
-- signature for call has to be inverted: TUPLE [T..NONE]..NONE

-- legal
an_agent.call ([T])
an_agent.call ([T, ...])
an_agent.call ([U, ...])

-- illegal
an_agent.call ([])
</e>

Instantiation:
<e>
agent_empty := agent () do end --> PROCEDURE [ANY, TUPLE []]
agent_any := agent (a: ANY) do end --> PROCEDURE [ANY, TUPLE [ANY]]
agent_t := agent (t: T) do end --> PROCEDURE [ANY, TUPLE [T]]
agent_u := agent (u: U) do end --> PROCEDURE [ANY, TUPLE [U]]

-- legal
an_agent := agent_empty
an_agent := agent_any
an_agent := agent_t

-- illegal
an_agent := agent_u
</e>

There might be a concern about the fact that the compiler generates the signature of the call method. But I think that its not wrong to have compiler support for agents, as they are such a fundamental core concept that is simply important that one could sacrifice expressive power or type safety just to avoid explicit support from the compiler.

== How to generate the call signature for a given agent type ==

<todo>