Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!jos@cs.vu.nl
From: jos@cs.vu.nl
Newsgroups: comp.lang.eiffel
Subject: generic parameters
Message-ID: <1826@vlot.cs.vu.nl>
Date: 19 Dec 88 13:10:46 GMT
Sender: jos@cs.vu.nl
Reply-To: jos@cs.vu.nl ()
Organization: VU Informatica, Amsterdam
Lines: 73

Hello to everybody on this brand new newsgroup.  I hope we will have
some useful discussions on this group.
Happy Christmas, happy new year and now to the point:

----------------------------------------------------------------------

I have some questions about the usage of generic parameters.

In the basic eiffel library there is a class TREE[T],
which has one generic parameter: T.

In Bertrand Meyer's book there is an example about a hierarchic
window class.  On page 284 the example looks like:

    class WINDOW export ..... inherit
	  TREE
	      rename
		  child as subwindow,
		  parent as superwindow,
		  insert_child as insert_subwindow, etc.
    ...

WINDOW inherits class TREE, but it does not specify the generic
parameter of TREE.

Questions:

    1. Is this correct Eiffel? (I can't find anything in the book about it)

    2a. If it is, what are the semantics of this kind of inheritance ?

    2b. If it is not, how should the WINDOW class inherit TREE ?

Possible answers:

    1+2a. This is correct Eiffel, and we have the following situation:

	local
	   t     : TREE   ;
	   w     : WINDOW ;
	   dummy : ???    ;

	   w.Create;
	   t = w;                 -- allowed, because w is an heir to t.

	   -- t.value can not be used, because its type is still generic T
	   -- the next call will always be rejected by the compiler,
	   -- no matter what the type of dummy is.

	   dummy = t.value;       

    1+2b. This is not correct Eiffel, and the correct definition
    of the class WINDOW should be:

	class WINDOW export ..... inherit
	      TREE[WINDOW]
		  rename
		      child as subwindow,
		      parent as superwindow,
		      insert_child as insert_subwindow, etc.
	...

     If we have an object w of type WINDOW, then w.child should be
     the same as w.child_value.  This looks suspicious, so I think
     this is not the right solution.


                                 Jos Warmer
				 jos@cs.vu.nl

PS.  We have ordered the compiler, but it hasn't arrived yet.
     So I can't try it out.  This is not too bad, now I actually
     have to *think* about it.