2008-11-01T23:16:34Z

Clemahieu:

[[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 obj
one := obj.one
two := obj.two
end
end
</e>

Implicit class

2007-11-21T16:38:35Z

Clemahieu:

{{Research}}

Requesting comments on the notion of an implicit class.

The basic idea would be performing the exact same functionality as the `Renaming' clause in formal generic constraints. Instead of defining the multiple conformance inline within the text of the class containing the formal generic that is constrained, the generic would have its own class file.

<eiffel>
implicit class A
inherit
B
rename
is_equal as b_is_equal
end
C
rename
is_equal as c_is_equal
end
end
</eiffel>

The following class:
<eiffel>
class F
inherit
B
C
end
</eiffel>

Could then be used like:
<eiffel>
feature operation is
local
item: F
container: LINKED_LIST[A]
val: BOOLEAN
do
val := {A}item.b_is_equals(void)
val := {A}item.c_is_equals(void)
create container.make
container.put({A}item)
end
</eiffel>

<eiffel>
class CONTAINER [G -> A]
end
</eiffel>

would be identical to ECMA
<eiffel>
class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}]
end
</eiffel>

Any class inheriting from B and C could be downcast to A. This simple change would facilitate clarity and reuse in formal generic parameters.

This would also allow multiple constraints to be easily adaptable to actual generic parameters.
container: LIST[A] would allow objects inheriting from B and C to be placed in `container' and features in B and C to be called on these objects inside of `container' using the renaming policy defined in `A'

Implicit class

2007-11-20T23:13:15Z

Clemahieu:

{{Research}}

Requesting comments on the notion of an implicit class.

The basic idea would be performing the exact same functionality as the `Renaming' clause in formal generic constraints. Instead of defining the multiple conformance inline within the text of the class containing the formal generic that is constrained, the generic would have its own class file.

<eiffel>
implicit class A
inherit
B
rename
is_equal as b_is_equal
end
C
rename
is_equal as c_is_equal
end
end
</eiffel>

The following class:
<eiffel>
class F
inherit
B
C
end
</eiffel>

Could then be used like:
<eiffel>
feature operation is
local
item: F
do
{A}item.b_is_equals
{A}item.c_is_equals
end
</eiffel>

<eiffel>
class CONTAINER [G -> A]
end
</eiffel>

would be identical to ECMA
<eiffel>
class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}]
end
</eiffel>

Any class inheriting from B and C could be downcast to A. This simple change would facilitate clarity and reuse in formal generic parameters.

This would also allow multiple constraints to be easily adaptable to actual generic parameters.
container: LIST[A] would allow objects inheriting from B and C to be placed in `container' and features in B and C to be called on these objects inside of `container' using the renaming policy defined in `A'

Implicit class

2007-11-20T23:12:59Z

Clemahieu:

{{Research}}

Requesting comments on the notion of an implicit class.

The basic idea would be performing the exact same functionality as the `Renaming' clause in formal generic constraints. Instead of defining the multiple conformance inline within the text of the class containing the formal generic that is constrained, the generic would have its own class file.

<eiffel>
implicit class A
inherit
B
rename
is_equal as b_is_equal
end
C
rename
is_equal as c_is_equal
end
end
</eiffel>

The following class:
<eiffel>
class F
inherit
B
C
end
</eiffel>

Could then be used like:
<eiffel>
feature operation is
local
item: F
do
{A}item.b_is_equals
{A}item.c_is_equals
end

<eiffel>
class CONTAINER [G -> A]
end
</eiffel>

would be identical to ECMA
<eiffel>
class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}]
end
</eiffel>

Any class inheriting from B and C could be downcast to A. This simple change would facilitate clarity and reuse in formal generic parameters.

This would also allow multiple constraints to be easily adaptable to actual generic parameters.
container: LIST[A] would allow objects inheriting from B and C to be placed in `container' and features in B and C to be called on these objects inside of `container' using the renaming policy defined in `A'

Implicit class

2007-11-20T23:06:33Z

Clemahieu:

{{Research}}

Requesting comments on the notion of an implicit class.

The basic idea would be performing the exact same functionality as the `Renaming' clause in formal generic constraints. Instead of defining the multiple conformance inline within the text of the class containing the formal generic that is constrained, the generic would have its own class file.

<eiffel>
implicit class A
inherit
B
rename
is_equal as b_is_equal
end
C
rename
is_equal as c_is_equal
end
end
</eiffel>

<eiffel>
class CONTAINER [G -> A]
end
</eiffel>

would be identical to ECMA
<eiffel>
class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}]
end
</eiffel>

Any class inheriting from B and C could be downcast to A. This simple change would facilitate clarity and reuse in formal generic parameters.

This would also allow multiple constraints to be easily adaptable to actual generic parameters.
container: LIST[A] would allow objects inheriting from B and C to be placed in `container' and features in B and C to be called on these objects inside of `container' using the renaming policy defined in `A'