Difference between revisions of "Implicit class"

Latest revision as of 16:29, 18 March 2008

Research: This page describes research about Eiffel, not the actual language specification.

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 and allowing new features to be applied to an object without modifying the original class text. 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. Any class that inherits from B and C could statically downcast that object to A. A validity constraint on the downcast would be class A cannot contain new attributes.

class A
inherit
B
rename
is_equal as b_is_equal
end
C
rename
is_equal as c_is_equal
end
feature
new_op: INTEGER is
  do
    result := b.val + c.val
  end
end

The following class:

class F
inherit
B
C
end

Could then be used like:

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

class CONTAINER [G -> A]
end

would be identical to ECMA

class CONTAINER [G -> {B rename is_equal as b_is_equal end, C rename is_equal as b_is_equal_end}]
end

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'