Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!dawg6844 From: dawg6844@uxa.cso.uiuc.edu (Race Bannon) Newsgroups: comp.lang.smalltalk Subject: Re: Access methods - New feature ? Keywords: Access methods, Smalltalk-80 Message-ID: <1991Apr22.003659.18658@ux1.cso.uiuc.edu> Date: 22 Apr 91 00:36:59 GMT References: <1991Apr21.221149.8057@vuse.vanderbilt.edu> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois at Urbana Lines: 24 brian@vuse.vanderbilt.edu (Brian Antao) writes: >an instance variable. The suggested feature would be, that the compiler/ >interpreter, by default inserts these methods corresponding to each instance >variable specified in the Class definition. Each time the Class definition is >recompiled, the appropriate access methods should be added/deleted if any >instance variables are added/deleted. One could also argue for a similar >feature to also support class variable access. This would not be difficult to add, just aesthetically unpleasant. Why? One of the primary ideas behind 'objects' is the encapsulation of data with the code that manipulates it. Why is this good? If used properly, it minimizes the 'side-effects' that can occur with other programming paradigms. In SmallTalk, no object can manipulate another's state unless you 'do it on purpose', by constructing the access methods to do so. If access methods were automatically generated for every private variable, then this breaks down; every object can diddle with the state of every other. Yes, frequently you need to write several access methods for several private variables of an object, but if you are finding that you need to make ALL of your instance variables public, then perhaps you need to rethink your design. -- _______________________________________________________________________________ Dan Walkowski | To understand recursion, Univ. of Illinois, Dept. of Comp. Sci. | you must first understand recursion. walkowsk@cs.uiuc.edu |