"Ian Oldham" <
[hidden email]> wrote in message
news:
[hidden email]...
> Using DPRO 5.1 pl1...
>
> if I've got a method such as:
> TestObject>>testMethod: aString
> (aString isNil or:[aString isEmpty]) ifTrue:[^nil].
> "some more code"
>
> and I step through it using the debugger the following sections of code
are
> highlighted, depending on the value of aString of course:
> aString isNil
> aString isEmpty
> ^nil
>
> i.e. I can't seem to get the or:[] or the ifTrue:[] to be highlighted.
>
> Looking at the results of (TestObject compiledMethodFor:
> #testMethod:)textMap and comparing that with the results of TestObject
> compiledMethodFor: #testMethod:)getSource I can see that these 'blocks' of
> source code are missing from the textMap. Is there any 'logical' reason
for
> this omission? I've tried with other block constructs such as
> ifTrue:[]ifFalse:[] and and:[] and I see the same results so I'm wondering
> whether it's something to do with the block closure itself.
Hi Ian,
What you are seeing is probably the result of these boolean "messages" not
being compiled as message sends. I think all modern Smalltalks do this.
Things like #ifTrue: when given a literal block argument are converted by
the compiler to jumps/gotos with equivalent semantics. This speeds up the
execution of programs a lot. The drawbacks are related to there not really
being messages, so the debugger behaves differently (IBM Smalltalk also has
something similar for simple accessors - other dialects probably have such
things too), things like finding senders work differently, and you can't
redefine the behavior. These drawbacks are seen as acceptable by most
implementers and most users who are aware of the phenomenon. VisualWorks
Smalltalk has a setting to give you some control over which selectors are
compiled away, so you can experiment with the effects, and not incur the
drawbacks if you are ready to forego the advantages, which is a rather nice
feature.
Regards,
Peter van Rooijen
Amsterdam
> Can CompiledCode>>textMap be modified to include the block closure
messages
> where appropriate?? My reason for asking is that I've (unashamedly) taken
> John Brant/Michel Tillman's Method Wrappers/Test Manager tool and
> 'Dolphinised' them. The icing on the cake is the highlighting of the
> executed code within a method but it looks a bit odd with these missing
> sections when I know that they have been executed.
>
> TIA, Ian Oldham
>
>
Locked
