Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!think!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive!decwrl!ucbvax!bloom-beacon!mcgill-vision!clyde.concordia.ca!doyle!marcap From: marcap@doyle.cs.concordia.ca (PAWLOWSKY marc) Newsgroups: comp.lang.eiffel Subject: BASIC TYPES Summary: The compiler should be able to handle basic types as normal objects Message-ID: <1864@clyde.concordia.ca> Date: 19 Feb 90 19:59:07 GMT Sender: usenet@clyde.concordia.ca Reply-To: marcap@doyle.CS.Concordia.CA (PAWLOWSKY marc) Organization: Concordia University, Montreal Quebec Lines: 52 ASSUMPTIONS: The definition for INTEGER is int.e (It inherits from comparable). The compiler handles basic types (INT, STRING, REAL, .. ) specially THE EXAMPLE ARRAYS that can be sorted. THE PROBLEM ec can not handle constraints on basic types. DISCUSSION Creating a constrained generic type is very basic to OOP and Eiffel in particular. However the basic types for 2.2 can not be passed as constrained parameters. This limitation is most annoying. Since to bypass it artificial types become necessary, making the situation more complex than necessary. For example the class ARRAY_COMPAR class ARRAY_COMPAR[T -> COMPARABLE] export repeat ARRAY, is_sorted, quick_sort, merge inherit ARRAY[T] rename Create as array_create can not be used with a basic type. Trying to do so results in the error message Eiffel compilation manager (version 2.2 level A) Pass 3 on class test_array_compar "test_array_compar", 15: Basic type may not be used as actual generic type corresponding to a constrained formal generic parameter es: error in pass3 I do not think the compiler should treat basic types any different from other types when being passed. If the resulting code is more inefficent than so be it. Otherwise a class is necessary for each basic type, as well as another class for non-basic types. I do not believe this is in the "spirit" of Eiffels concepts on reusability. Marc Pawlowsky Graduate Student Concordia University