John M McIntosh wrote:
> 
> At 4:01 AM +0100 12/28/01, Stephan Rudlof wrote:
> >
> >Which source code? The ST #assert: throws an exception and therefore halts
> >the program, what is quiet similar to my assert (I admit that the ST one is
> >not as radical).
> >
> >I don't want to ride the horse to death (correct?). If you and others are
> >lucky with it, let it be #sqAssert:. But then populate please (e.g. by ST
> >and/or Swiki docu), that it is *forbidden* to use an assert() function like
> >the ST #assert: in Slang, since it would conflict with the Unix one (after C
> >code generation). Otherwise others could easily walk into the same trap
> >(mostly it would work with their platform, but not with all).
> >
> Is this a compromise?
> 
> Yes, it's quite workable. Now if someone wants to resubmit a change
> set to clean this up, that would be great.
> 
> Note the usages below.
> 
> It would seem that BalloonEngineSimulation>>assert: should really use
> the Object>>assert: which means some changes because one expects a
> block, the other a boolean. Which is correct is a  question? SUnit
> expects a boolean, perhaps our usage on Object as a block should
> change to avoid confusion.
> 
> Perhaps a better name for the plugin assert is sqPluginAssert? I'm
> also assuming this could be folded into InterpreterPlugin? Printing a
> message, is ok, but I wonder if we want to also print a stack trace
> too before doing the exit(1), or is that a primitiveFail and return
> we want (I suspect so?) This implies doing a return will be ok, or do
> we need sqPluginAssertExit & sqPluginAssertReturn?
> 
> TestCase>>assert: aBoolean
>          aBoolean ifFalse: [self signalFailure: 'Assertion failed']
> 
> Object>>assert: aBlock
>         "Throw an assertion error if aBlock does not evaluates to true."
> 
>         aBlock value ifFalse: [AssertionFailure signal: 'Assertion failed']
> 
> BalloonEngineSimulation>>assert: bool
>         bool ifFalse:[^self error:'Assertion failed'].
> 
> LargeIntegersPlugin>>assert: aBool
>         self
>            debugCode:
>                 [aBool ifFalse:
>                         [self msg: 'Assertion failed!'.
>                         self cCode: 'exit(1)'
>                         inSmalltalk:
>                         [interpreterProxy primitiveFail.
>                         self halt]].
>                         ^ true]

My last [ENH] suggestion was to kick this >>assert: and to use a modified
one:
TestInterpreterPlugin>>
sqAssert: aBool 
	self
		debugCode: [aBool
				ifFalse: [self error: 'Assertion failed!'].
			^ aBool]

This eliminates any assert() calls in production code and results in an
exit() call (see error() in interp.c) with call stack printing for debug
code.

See
       TIPlugin-cleanup-sr.1.cs.gz
in mail subjected
        [ENH] TestInterpreterPlugin-cleanup-sr
.

For me this is a simple variant for developer code and *documentation*
purposes (>>sqAssert:'s say something about the semantics of the code!).
The question remains if it makes sense to provide a more complicated variant
with >>primitiveFail semantics. For me the simple one is at least a good
start.


Greetings,

Stephan


> --
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3