Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!kth!luth!mikael From: mikael@sm.luth.se (Mikael Eriksson) Newsgroups: comp.lang.eiffel Subject: Re: Eiffel compilers and generics (parameterized classes) Message-ID: <232@my6.sm.luth.se> Date: 3 Mar 89 15:35:06 GMT References: <45493@linus.UUCP> Sender: mikael@sm.luth.se Reply-To: Mikael Eriksson Organization: University of Lulea, Sweden Lines: 42 UUCP-Path: {uunet,mcvax}!enea!my6.sm.luth.se!mikael In article <45493@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes: >I've been programming in Ada for some years now, yet I remain >disappointed in how badly Ada compilers deal with generics >(parameterized program units). > > How well >do Eiffel compilers do with parameterized classes? Are separate >compilation facilities reliable? Is the library manager robust and >"industrial-strength"? Disclaimer: I havent tried to use eiffel yet so this is just educated guesses. In eiffel generics are much easier to handle than in ADA. It also only has generic types, not generic subprograms. Since everything in an eiffel program is objects the compiler knows how many bytes the objects of the parameter class is going to take. (The size of a pointer.) It is also only allowed to do operations on generic objects that can be done on objects of all classes. This can be easily implemented. The above discussion only covers parameterized classes. Another form of generics is given by using inheritanse. Take the classic example of a list that contains graphic elements that can be circles, polygons or lines. The list can then be seen as generic with the limitation that the objects in list must be descendants of the graphic class. This can in some cases be more powerful than the parameterized classes since it is possible to do more things with the objects in the list than just storing them. Both forms of generics are of course wery useful. >Steven Litvintchouk >MITRE Corporation >Burlington Road >Bedford, MA 01730 > -- Mikael Eriksson (Email: mikael@sm.luth.se) ......... You are in error. 2+2=5 Thank you for your cooperation. The Computer.