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
> >
> >
>