Clemahieu at 23:16, 1 November 2008

2008-11-01T23:16:34Z

Clemahieu at 19:55, 31 October 2008

2008-10-31T19:55:51Z

New page

[[Category:ECMA]]
{{Research}}

Motivation:
*Remove the need for adapter classes.
*Reconcile the relatively loose conventions around agents in to the more strict conventions of inheritance.

Similarity between adapter classes and agents
----
Take the starting classes A and B:
<e>
class A
feature
process_1
do
-- Operate on value_1
end
value_1: INTEGER
test_1: BOOLEAN
process_2
do
-- Different operation on value_2
end
value_2: INTEGER
test_2: BOOLEAN
end
</e>

<e>
deferred class B
feature
process
deferred
end
value: INTEGER
deferred
end
test: BOOLEAN
deferred
end
end
</e>

And adapters C and D:
<e>
class C
inherit
B
feature
make (sourceA: A)
do
source := sourceA
end
source: A
process
do
source.process_1
end
value: INTEGER
do
result := source.process_1
end
test: INTEGER
do
result := source.test_1
end
end
</e>
<e>
class D
inherit
B
feature
make (sourceA: A)
do
source := sourceA
end
source: A
process
do
source.process_2
end
value: INTEGER
do
result := source.value_2
end
test: BOOLEAN
do
result := source.test_2
end
end
</e>

Using these adapters, if A wanted to provide clients access to itself in 2 different ways through B, the following features could be added to A:
<e>
class A
--Same features as above--
feature
one: B
do
result := create {C}.make (current)
end
two: B
do
result := create {D}.make (current)
end
end
</e>

Another way A could provide access to itself similar to B is by use of agents:
<e>
class A
--Same features as above--
feature
one: TUPLE [process: PROCEDURE [ANY, []], value: FUNCTION[ANY, [], INTEGER], test: FUNCTION[ANY, [], BOOLEAN]]
do
result.process := agent process_1
result.value := agent value_1
result.test := agent test_1
end
two: TUPLE [process: PROCEDURE [ANY, []], value: FUNCTION[ANY, [], INTEGER], test: FUNCTION[ANY, [], BOOLEAN]]
do
result.process := agent process_2
result.value := agent value_2
result.test := agent test_2
end
end
</e>

Disadvantages of adapters:
*Requires 1 new class for every way a class wishes to provide facilities to clients.

Disadvantages of agents:
*Requires a new, though already implemented, language construct `agents'.
*Strongly typed contracts related to agents are not defined.

Implementation of A using named inheritance:
----
<e>
class A
inherit
one: B
rename
process as process_1,
value as value_1,
test as test_1
end
two: B
rename
process as process_2,
value as value_2,
test as test_2
end
feature
process_1
do
-- Operate on value_1
end
value_1: INTEGER
test_1: BOOLEAN
process_2
do
-- Different operation on value_2
end
value_2: INTEGER
test_2: BOOLEAN
end
</e>

A client of A could make use of the named inheritance functionality as such:
<e>
class APPLICATION
feature
make
local
obj: A
one: B
two: B
do
create A
one := a.one
two := a.two
end
end
</e>

@@ Line 178: / Line 178: @@
 two: B
 do
-create A
+create obj
-one := a.one
+one := obj.one
-two := a.two
+two := obj.two
 end
 end
 </e>

Named Inheritance - Revision history

Clemahieu at 23:16, 1 November 2008

Clemahieu at 19:55, 31 October 2008