Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!think!snorkelwacker!bloom-beacon!bu.edu!bu-cs!purdue!mentor.cc.purdue.edu!gza
From: gza@mentor.cc.purdue.edu (William R Burdick)
Newsgroups: comp.object
Subject: Re: Atomic Objects and Identity (was Re: Evaluating "Object-Oriented" Progra)
Message-ID: <GZA.90Feb5103156@mentor.cc.purdue.edu>
Date: 5 Feb 90 15:31:56 GMT
References: <2740@tukki.jyu.fi> <1990Jan31.052750.22507@Neon.Stanford.EDU>
Sender: news@mentor.cc.purdue.edu
Distribution: comp
Organization: Team Cthulhu
Lines: 46

I didn't catch the whole discussion on this:

In article <1990Jan31.052750.22507@Neon.Stanford.EDU>, Joe Pallas wrote:
    In article <2740@tukki.jyu.fi>, Markku Sakkinen wrote:

      Regarding Booleans, the fact that True and False need to be singleton
      subclasses is an ugly wart that in my opinion shows a flaw in the
      Smalltalk philosophy.

but, it  seems  to  me  that if  you  look in the  class  hierarchy in
Smalltalk, you'll find a class  called 'Behavior.'  This is because  a
class is simply a definition of how an object behaves.  So if you want
to provide  two objects which  you deem to have sufficiently different
behavior, you should make different classes for them.

True and False don't *need*  to be  singleton subclasses; the folks at
PARC could as well have written a primitive which looked at  the value
of the receiver and then  did the if-thing  -- but what's the point of
that?  I don't see  having singleton subclasses as a  wart  or a flaw,
it's  just a different   approach than  other  people  might have, but
equally valid.  It's obvious that true objects behave differently from
false objects.  A  valid approach to modeling the  behavior is to make
two different classes (behaviors) for them.

The Smalltalk developers could have made t and nil be instances of the
same class  and dispensed with  the True,  False,  and UndefinedObject
classes  (maybe rename Boolean    to  SimpleConstant -- or   just  use
numbers, like in C, then we  can get rid  of BOTH booleans!)  but they
chose  to  put   more structure in the  definition   than that.  IMHO,
there's nothing wrong with making more classes if it improves clarity.
The point of writing in Smalltalk is to make the  code clear.  Lumping
together different behaviors  into the same class defeats   this.   Of
course,  it is a  personal decision whether to  use class  or state to
decide behavior.

The true and false objects in Smalltalk are like quanta -- they are so
primitive  that their definition easily wavers  between two objects of
different classes and two objects of the same class.   There must be a
point where the system breaks  down and becomes inconsistant (honest),
and no matter which 'ugly wart' you remove,  you'll find one more just
waiting for you!


--
	-- Bill Burdick
	burdick@cello.ecn.purdue.edu