Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!emory!mephisto!prism!tynor
From: tynor@prism.gatech.EDU (Steve Tynor)
Newsgroups: comp.lang.eiffel
Subject: Re: BASIC TYPES
Message-ID: <6285@hydra.gatech.EDU>
Date: 22 Feb 90 23:13:15 GMT
References: <1864@clyde.concordia.ca> <251@eiffel.UUCP> <1799@novavax.UUCP> <254@eiffel.UUCP>
Reply-To: tynor@prism.gatech.EDU (Steve Tynor)
Organization: Georgia Institute of Technology
Lines: 41

In article <254@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>From <1799@novavax.UUCP> by weiner@novavax.UUCP (Bob Weiner):
>
>> Rather than sprinkle pre- and post-conditions around routines that say:
>> 
>>     require
>>        param > 0
>> 
>> and other such things, it makes sense to create classes for POS_INT,
>> NON_NEG_INT and so forth and then type the formal parameters of the
>> routines.
...
>    In all these cases we will have to resort to assertions anyway.
...

It's really a case of where we have to assert. Surely much better in a class
than in each of its uses since the constraint is a property of the class.

Perhaps, for efficiency's sake, it would be acceptable to dissallow
multiple inheritance and feature (re)defintion for descendants of
basic types. Thus:

   class INTERVAL_1_10 export
      repeat INTEGER	
   inherit
      INTEGER
   invariant
      Current >= 1 and Current <= 10;
   end

Sure, this restricts us to static interval bounds, but then this is
all most programming languages provide. And it's better than what we
have now.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
inherit STD_DISCLAIMER;
                     
    Steve Tynor
    Georgia Tech Research Institute
    Artificial Intelligence Branch
    tynor@prism.gatech.edu