Ok, the code in my previous post had a couple of issues, but attached is a
change set that addresses the problem, and doesn't require changes to
existing code in Squeak (I think).

Object>>assert does nothing by default, and is overridden by subclasses to
specialize the determination of whether an object is in a "consistent
state"...if not, this method should signal the assertion exception.

Object>>assert: simply redispatches #assert, override this if you want your
subclasses to make assertions on other objects and handle them differently
that #assert: or #assert normally does.

True>>assert does nothing

False>>assert signals the assertion exception

BlockContext>>assert does "(self value == true) assert"

- Stephen

> -----Original Message-----
> From: Stephen Pair [mailto:spair at advantive.com]
> Sent: Tuesday, June 12, 2001 2:28 PM
> To: squeak at cs.uiuc.edu
> Subject: RE: [BUG] two different ways to handle assert:
>
>
> It's not good to implement Boolean>>value just so that it can be passed to
> #assert:.  I would avoid diluting the Boolean protocol
> (especially with the
> message #value) just for the sake of avoiding a larger amount of
> work...better to make things work right than hack around the
> problem (IMO).
>
> I suppose that you want to pass a block to #assert: so that you can
> implement a mechanism to turn on and off assertions, correct?  If this is
> this case, the protocol had better be well defined, otherwise,
> people could
> make assertions with behavior that is critical to the working of a
> method...then when assertions are turned off...boom...code breaks.
>
> What if #assert were defined for any object to mean: "does this
> object exist
> in a consistent state?"  The method #assert: would redispatch
> #assert to its
> argument providing that assertions are enabled.  Overriding #assert: would
> be done when the normal response to an assertion failure needs to be
> customized.  Overriding #assert would be done in cases where you wanted to
> redefine what it means to be "in a consistent state" for a given class of
> objects.  Here's some example code:
>
> -----
> Object>>assert: aBlockOrBool
>
> 	Preferences assertionsEnabled ifTrue: [
> 		aBlock assert ifFalse: [
> 			^self throwAssertionError
> 		].
> 	].
>
> -----
> Object>>assert
> 	^true
>
> -----
> True>>assert
> 	^self
>
> -----
> False>>assert
> 	^self
>
> -----
> BlockContext>>assert
>
> 	self value assert
>
> -----
> Person>>assert
>
> 	^self ageInDays == (Date today - self birthDate)
> -----
>
> This code would allow all of:
>
> self assert: [ 1 = 1 ].
> self assert: (1 = 1).
> self assert: aPerson.
>
> The False singleton would always be considered "in an inconsistent state."
> Perhaps to avoid confustion, a different selector could be used
> for #assert
> (i.e. #isConsistent).
>
> - Stephen
>
> > -----Original Message-----
> > From: Pablo Murias [mailto:p.murias at mercapsoftware.com]
> > Sent: Tuesday, June 12, 2001 4:23 PM
> > To: squeak at cs.uiuc.edu
> > Subject: Re: [BUG] two different ways to handle assert:
> >
> >
> > I think that we must have only one way of handle #assert:.
> > If you implement #assert: assuming that the argument is a block that
> > evaluates to a boolean, or an object that understand value and answer a
> > boolean (this is the reason to implement Boolean>value), then you
> > don't have
> > to rewrite the senders of #assert:, only the implementors.
> >
> > cheers, Pablo
> >
> >
> >
> > ----- Original Message -----
> > From: "Daniel V. Oppenheim" <music at watson.ibm.com>
> > To: <squeak at cs.uiuc.edu>
> > Sent: Tuesday, June 12, 2001 8:24 AM
> > Subject: Re: [BUG] two different ways to handle assert:
> >
> >
> > > Pablo
> > >
> > > The problem is that the system has two different
> implementations -- one
> > > expects a block as argument, the other a boolean. This is not good.
> > >
> > >          Danny
> > >
> > > At 11:09 AM 6/12/01 -0700, you wrote:
> > > >You can expect allways a block, and implement
> > > >
> > > >Boolean>>value
> > > >        ^self
> > > >
> > > >
> > > >By the way, this is my first message to the list and I must
> say thanks
> > for
> > > >Squeak to the people that made it and to all the people that works to
> > make
> > > >it better
> > > >
> > > >Pablo
> > > >
> > > >
> > > >----- Original Message -----
> > > >From: "Daniel V. Oppenheim" <music at watson.ibm.com>
> > > >To: "Squeak Mailing List" <squeak at cs.uiuc.edu>
> > > >Sent: Monday, June 11, 2001 1:26 PM
> > > >Subject: [BUG] two different ways to handle assert:
> > > >
> > > >
> > > > > The system handles <assert:> in two different ways:
> Object expects a
> > Block
> > > > > as argument, whereas all other 3 classes expect a Boolean.
> > This is not
> > a
> > > > > good idea... However, there are only 39 senders so its an
> easy fix;
> > > > > slightly complicated with the implementation of <assert> in
> > BlockContext,
> > > > > but that only has 7 senders.
> > > > >
> > > > > I think aBoolean makes more sense than aBlock as argument.
> > > > >
> > > > > Since I need to fix this anyhow in order to file in my own
> > code I will
> > be
> > > > > happy to make the change, update all system methods, and
> > send the fix
> > > >in --
> > > > > but being new to the squeak-fix process please let me know
> > what is the
> > > > > preferred way of handling this.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Danny Oppenheim
> > > > > ---
> > > > >
> > > > > Dr. Daniel V.
> > > > > Oppenheim
> > > > >
> > > > > Computer Music Center
> > > > > IBM T.J. Watson Research Center      phone: (914) 945-1989
> > > > > P. O. Box 218 (or Route 134)      fax:   (914) 945-3434
> > > > > Yorktown Heights, NY 10598      www.research.ibm.com/music
> > > > >
> > > > >
> > >
> > > ---
> > >
> > > Dr. Daniel V.
> > > Oppenheim
> > >
> > > Computer Music Center
> > > IBM T.J. Watson Research Center      phone: (914) 945-1989
> > > P. O. Box 218 (or Route 134)      fax:   (914) 945-3434
> > > Yorktown Heights, NY 10598      www.research.ibm.com/music
> > >
> > >
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: assert.3.cs
Type: application/octet-stream
Size: 1146 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010612/5a542532/assert.3.obj