PR# 19501 Type system broken

With the version of EiffelBase currently in SVN (svn#102530) the Gobo compiler reports these two errors:

~~~~~~~~~~~~~~~~~~~
[VDRD-2] class LINKED_TREE (15,2): signature of selected feature `new_cursor' inherited from DYNAMIC_TREE does not conform to the signature of replicated feature `new_cursor' in parent LINKED_LIST.
[VDRD-2] class TWO_WAY_TREE (15,2): signature of selected feature `new_cursor' inherited from DYNAMIC_TREE does not conform to the signature of replicated feature `new_cursor' in parent TWO_WAY_LIST.
~~~~~~~~~~~~~~~~~~~

Indeed, if we write this code:

~~~~~~~~~~~~~~~~~~~
	make
		local
			l_tree: LINKED_TREE [INTEGER]
			l_list: LINKED_LIST [INTEGER]
			l_cursor: LINKED_LIST_ITERATION_CURSOR [INTEGER]
		do
			create l_tree.make (5)
			l_list := l_tree
			l_cursor := l_list.new_cursor
			if not attached {LINKED_LIST_ITERATION_CURSOR [INTEGER]} l_cursor then
				print ("Type system broken%N")
				print ("Cursor type: " + l_cursor.generating_type.name + "%N")
			end
		end
~~~~~~~~~~~~~~~~~~~

and compile it with EiffelStudio, we get:

~~~~~~~~~~~~~~~~~~~
Type system broken
Cursor type: TREE_ITERATION_CURSOR [INTEGER_32]
~~~~~~~~~~~~~~~~~~~

I hope that this can be fixed before the release of 18.11.

--
Eric Bezault

The issue is fixed using option 4.

Option 3 is what I did in Gobo as a temporary solution (we need to exclude two cursor classes as well).
I just checked, and our code at AXAR does not seem to use these two tree classes. So this is fine with me.

As for option 4, it cannot be worse to have a cursor class which inherits from a tree cursor class and a linked list cursor class than having linked tree class which inherits from a tree class and a linked list class.

--
Eric Bezault

Option 2) turns out to be not that simple because LINKED_TREE exposes too much internal details, e.g. it allows for adding subtrees directly, whereas LINKED_LIST allows for adding values, but not list elements that hold values.

There are some other options as well:
3) exclude the classes from the base library (unless they are used somewhere);
4) add new cursor types, e.g. LINKED_TREE_ITERATION_CURSOR that would inherit from both LINKED_LIST_ITERATION_CURSOR and TREE_ITERATION_CURSOR.

Option 3) seems to be most efficient, but it may break projects that rely on the classes.
As to option 4), it's unclear, whether it is feasible - it may lead to some issues (such as CAT-calls) caused by repeated inheritance and redeclarations.

At first glance I only see two solutions:

1) Use non-conforming inheritance for LINKED_LIST [G], but last time I spoke about non-conforming inheritance with Manu, he told be that the current implementation was buggy and that we should not use it yet.
2) Do like in FIXED_TREE and declare the linked list of children as attribute instead of through inheritance.

--
Eric Bezault