The previous change set contained True>>assert, which is unnecessary because
its implementation is no different than Object>>assert.

- Stephen

> -----Original Message-----
> From: Stephen Pair [mailto:spair at advantive.com]
> Sent: Tuesday, June 12, 2001 2:59 PM
> To: squeak at cs.uiuc.edu
> Subject: [FIX] assertions (was: [BUG] two different ways to handle
> assert:)
>
>
> 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.4.cs
Type: application/octet-stream
Size: 1021 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010612/7f11fa48/assert.4.obj