Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!apple!agate!ucbvax!hplabs!hp-sdd!apollo!apollo.hp.com!yon
From: yon@apollo.HP.COM (David Yon)
Newsgroups: comp.lang.smalltalk
Subject: Data-Hiding?  Really??
Message-ID: <4811d5e9.20b6d@apollo.HP.COM>
Date: 16 Jan 90 14:03:00 GMT
Sender: root@apollo.HP.COM
Reply-To: yon@apollo.HP.COM (David Yon)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 65


	One of the supposed strong points of Smalltalk and
Object-Oriented programming is the enforcement of Data-Hiding
and Encapsulation. That is to say, only an Object can access
and modify it's own instance variables.

	On the other hand, this is not entirely true.  Say
for example we have two object classes:  Apple, and AppleBasket.
AppleBasket has one instance variable called "theApple", and
Apple has an instance variable called "howRipe".  AppleBasket
has the following methods:

getApple
	"Answer the Apple in the Basket"

	^theApple.

---
putApple: anApple
	"Set the Apple in the Basket"

	theApple := anApple.

---

	Apple has the following methods:

setRipeness: anInteger
	"Set the Ripeness of the Apple"

	howRipe := anInteger.

---
getRipeness
	"Answer the Ripeness of the Apple"

	^howRipe.

---

	Now, if you evaluate the following:

| apple basket integer anotherApple |

	apple := Apple new.
	apple setRipeness: 6.
	basket := AppleBasket new.
	basket putApple: apple.
	anotherApple := basket getApple.
	anotherApple setRipeness: 5
	basket inspect.

---
	You'll find that by setting the ripeness factor of the 
anotherApple variable, it changed the state of the object in the
AppleBasket.  So the ripeness of the Apple in the AppleBasket will
have been changed to five.  On the surface, this appears to violate
the rule that only objects can change their own state.

	Any thoughts on this?

David Yon

PS: this is not a flame on Smalltalk, I happen to LOVE working in
the environment.  This is just an anomoly I hadn't thought of before.