Immutable Interface - Revision history

Conaclos: English corrections

2014-02-01T18:20:44Z

English corrections

Conaclos: Minor corrections

2013-08-29T12:43:20Z

Minor corrections

Conaclos: tag correction

2013-08-19T13:36:35Z

tag correction

Conaclos: Page creation

2013-08-19T13:33:04Z

Page creation

New page

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

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

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

ANY commands:
<e>
class interface
ANY

feature -- Duplication

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

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

feature -- Basic Operations

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

frozen do_nothing
-- Execute a null action.

feature -- Output

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

end
</e>

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

* The command 'do_nothing' is a procedur especially interresting for agent uses.
A qualified call of 'do_nothing' on any objects is not usefull. An interresting use can be:
<e>
class
EXAMPLE

feature

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

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

end
</e>

However the contravariance of the second generic parameter of PROCEDURE can remove this use:
<e>
class
EXAMPLE

feature

do_something
do
do_something_with (agent do_nothing)
end

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

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

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

* The commands 'copy' and 'deep_copy' give us a challenge. Indeed they are used in queries ('twin' and 'deep_twin').
We can note that they are mainly used to initialize a freshly created object.

We can imagine that 'twin' and 'deep_twin' create a new object and then apply 'copy' or respectively 'deep_copy'.
This process does not folow the Eiffel creation phillosophy.
Maybe it is an opportunity to correct it and then to concretise the queries 'twin' and 'deep_twin' with Eiffel code.

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

create
copy,
deep_copy,
default_create

feature {NONE}-- Duplication

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

-- ...

feature -- Duplication

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

-- ...

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

To remove this issue we can introduce the inherited creation commands.

=== Inherited creation commands ===
A simple addition to Eiffel could be to allow the create clause in the deferred classes.
The creation commands declared in deferred classes would be inherited creation commands.

<e>
deferred class
A

create -- inherited
make

feature -- Initialization

make (a_n: INTEGER)
do end

end
</e>
<e>
class
B

inherit
A

create
-- make is a creation procedure

end
</e>

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

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

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

<e>
deferred class
ANY

create -- inherited creation commands
copy,
deep_copy

feature
-- ...

end
<e/>

== Conclusion ==
The proposition allows the design of full immutable interfaces.

The inherited creation command is a minimal mechanism compatible with existing software. It introduces no new keyword.
it allow to concretise two querise of ANY in Eiffel code and to export to no classes two problematic commands.

@@ Line 94: / Line 94: @@
 Therefore the command 'do_nothing' can be exported to no classes.
-* The command 'print' can be called only with unqualified calls. It can be too exported to no classes.
+* The command 'print' could be called only with unqualified calls. It can be too exported to no classes.
 * The commands 'copy' and 'deep_copy' are probably used mainly through the queries 'twin' and respectively 'deep_twin'.
@@ Line 149: / Line 149: @@
 === Inherited Creation Command ===
-A simple addition to Eiffel could be to allow the create clause in the deferred classes.
+A simple addition to Eiffel could be to allow the create clause in deferred classes.
 The creation commands declared in deferred classes would be inherited creation commands, i.e. creation commands implicitly declared in each descendants.
 If an effective class declares no new creation commands then all inherited creation commands and the command 'default_create' are creation commands.
 If an effective class declares new creation commands then all inherited creation commands and new ones are creation commands.
-An inherited command can be declared again in an effective class. This possibility allows then all inherited commands as creation commands without 'default_create' (except if 'default_create' is an inherited creation command).
+An inherited creation command can be declared again in an effective class. This possibility allows then all inherited commands as creation commands without 'default_create' (except if 'default_create' is an inherited creation command).
 <e>
@@ Line 204: / Line 204: @@
 === ANY and inherited creation commands ===
 The mechanism described in the previous section is not usable on ANY. Indeed, ANY is an effective class.
-However it is very useful to allow the creation of ANY instance?
+However is it very useful to allow the creation of ANY instance?
-I have no example of use of ANY instances. Maybe it is more relevant to make ANY as deferred class and then to use the inherited creation command mechanism.
+I have not examples of use of ANY instances. Maybe it is more relevant to make ANY as deferred class and then to use the inherited creation command mechanism.
 <e>

@@ Line 3: / Line 3: @@
 {{Research}}
 == Introduction ==
-Eiffel Base 2 relies on immutable interfaces to design better abstractions and to allow a better use of the library.
+Eiffel Base 2 relies on partial (see below) immutable interfaces to design better abstractions and to allow a better use of the library.
-This page sketch a solution to allow immutable interface designs.
+This page sketch a solution to allow full immutable interface designs.
 == Definition ==
-An interface is immutable if it exports only queries. The routines exported to no classes are not included in the interface.
+An interface is immutable if it exports only queries. The routines exported to no classes are not included in the class interface.
-Note that an immutable class has an immutable interface. However queries must be pures, i.e. with no side-effect.
+Note that an immutable class has an immutable interface and more queries must be pure, i.e. with no side-effect.
 == Issue ==
 Immutable interfaces are not conceivable in the current state of the Eiffel Standard.
-Indeed, all classes inherit of ANY. However ANY exports some commands. Therefore no immutble interface is conceivable.
+Indeed, all classes inherit of ANY. However ANY has not an immutable interface, it exports some commands. Therefore no immutable interface is conceivable.
-ANY commands:
+ANY class interface (queries are omitted):
 <e>
 class interface
@@ Line 57: / Line 57: @@
 * The command 'default_rescue' allows to change an internal behavior. This command can be exported to no classes.
-* The command 'do_nothing' is a procedur especially interresting for agent uses.
+* The command 'do_nothing' is a procedure specially interesting for agent uses.
-A qualified call of 'do_nothing' on any objects is not usefull. An interresting use can be:
+A qualified call of 'do_nothing' on any objects is not useful. An interesting use can be:
 <e>
 class
@@ Line 76: / Line 76: @@
 </e>
-However the contravariance of the second generic parameter of PROCEDURE can remove this use:
+However the contravariance (concept not introduced yet) of the second generic parameter of PROCEDURE can remove this use:
 <e>
 class
@@ Line 96: / Line 96: @@
 * The command 'print' can be called only with unqualified calls. It can be too exported to no classes.
-* The commands 'copy' and 'deep_copy' give us a challenge. Indeed they are used in queries ('twin' and 'deep_twin').
+* The commands 'copy' and 'deep_copy' are probably used mainly through the queries 'twin' and respectively 'deep_twin'.
-We can note that they are mainly used to initialize a freshly created object.
+Export this commands to no classes seems have no important disturbance. It is always possible to export its in descendants.
-We can imagine that 'twin' and 'deep_twin' create a new object and then apply 'copy' or respectively 'deep_copy'.
+However, we can easily imagine that 'twin' and 'deep_twin' create a new object and then apply 'copy' and respectively 'deep_copy'.
-This process does not folow the Eiffel creation phillosophy.
+This process does not follow the Eiffel creation philosophy.
-Maybe it is an opportunity to correct it and then to concretise the queries 'twin' and 'deep_twin' with Eiffel code.
+Maybe it is an opportunity to correct it and then to write the queries 'twin' and 'deep_twin' with Eiffel code.
 A solution would be to make both commands as creation commands.
@@ Line 113: / Line 113: @@
 	default_create
-feature {NONE}-- Duplication
+feature {NONE}-- Initialization
 	copy (other: like Current)
@@ Line 144: / Line 144: @@
 </e>
 The both commands can be exported to no classes and two queries can be writed in Eiffel code.
-However the developper must declare the creation commands for ecah effective class.
+However the developer must declare the creation commands for each effective class.
-To remove this issue we can introduce the inherited creation commands.
+To remove this issue we can introduce the inherited creation command mechanism.
-=== Inherited creation commands ===
+=== Inherited Creation Command ===
 A simple addition to Eiffel could be to allow the create clause in the deferred classes.
-The creation commands declared in deferred classes would be inherited creation commands.
+The creation commands declared in deferred classes would be inherited creation commands, i.e. creation commands implicitly declared in each descendants.
 <e>
@@ Line 162: / Line 166: @@
 	make (a_n: INTEGER)
-		do end
+		deferred end
 end
@@ Line 169: / Line 173: @@
 class
+	B
 inherit
@@ Line 174: / Line 190: @@
 create
-	-- make is a creation procedure
+	make
 end
 </e>
 This addition does not affect existing code. The compatibility is preserved.
-And more it can be usefull in constrained generic context.
+And more it can be useful in constrained generic context.
 === ANY and inherited creation commands ===
-The mechanism described in the previous section is not usable on ANY. Indeed, ANY is an effetcive class.
+The mechanism described in the previous section is not usable on ANY. Indeed, ANY is an effective class.
-However it is very usefull to allow the creation of ANY instance?
+However it is very useful to allow the creation of ANY instance?
 I have no example of use of ANY instances. Maybe it is more relevant to make ANY as deferred class and then to use the inherited creation command mechanism.
@@ Line 201: / Line 221: @@
 end
 </e>
 == Conclusion ==
-The proposition allows the design of full immutable interfaces.
+Export all ANY class's commands allows the design of full immutable interfaces.
-The inherited creation command is a minimal mechanism compatible with existing software. It introduces no new keyword.
+In addition, the inherited creation command concept is a minimal mechanism compatible with existing software. It introduces no new keyword and allows to write two queries of ANY in Eiffel code.
-it allow to concretise two querise of ANY in Eiffel code and to export to no classes two problematic commands.