From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8ff80a74f45b5cd3 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,8ff80a74f45b5cd3 X-Google-Attributes: gidfac41,public From: Peter Horan Subject: Re: Visibility and access to "public" attributes Date: 1997/09/02 Message-ID: <340B8771.424A@deakin.edu.au>#1/1 X-Deja-AN: 269501449 References: <872873007.3110@dejanews.com> Organization: School of Computing and Mathematics, Deakin University Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-02T00:00:00+00:00 List-Id: Don Harrison wrote: > > Mike Card wrote: > > [..] > :I know that Eiffel can totally hide the attributes of an object (i.e. > :accessed via methods only) as well. When writing Eiffel programs, how > :do you decide when to make a type's attributes "read-only visible" > :and when to hide them? > > You export them when they're needed (or may be needed) by clients; otherwise, > you hide them. > One must export parameters and functions when they are needed to verify pre-conditions. This is an Eiffel validity requirement (VAPE). (I am reminded of keeping one's fingers crossed when making promises :-)). This does not apply to features in post-conditions and invariants, which may be more restrictive than the client needs without harm. -- Peter Horan School of Computing and Mathematics peter@deakin.edu.au Deakin University +61-3-5227 1234 (Voice) Geelong, Victoria 3217, AUSTRALIA +61-3-5227 2028 (FAX) http://www.cm.deakin.edu.au/~peter