[Pharo-project] Issue 2559 in pharo: Senders of #ifNotNil: do not show

pharo at googlecode.com pharo at googlecode.com
Fri Apr 1 20:48:47 CEST 2011

Comment #8 on issue 2559 by nicolas.... at gmail.com: Senders of #ifNotNil: do  
not show

Dependencies: Compiler-nice.279

Let special selectors be a bit less special.
Special selectors are inlined by the compiler if receiver and arguments  
follow certain rules (like being a block with prescribed number of  
Inlining is very important for speeding up execution but there was a price  
to pay:

1) Until now,  in case the rules are not followed, Compiler would sometimes  
send the message as an ordinary one, and would sometimes refuse to compile  
(though I already relaxed the rules a lot in the past few years).
2) Also you could not browse reference to them because they were inlined  
and had no marker in CompiledMethod.
3) And Compiler would refuse to cascade them because inlining was harder to  
implement in such case.

Now, you can.
1) not respect the rules (in this case the message will always be sent)
2) browse references (there is literal added to the compiled code)
3) cascade (in a cascade, no message is inlined)

While at it I removed the odd rules for compiling caseOf: and that  
simplifies Compiler.

There is no support yet to prevent inlining, and thus to enable true  
(if receiver/arguments respect the rules, message won't be sent but still  
inlined with a hardcoded implementation).
However, you can hack by using any other argument but a Block:

(2>1) ifTrue: ['print me'] yourself.

This way you could activate your own override of ifTrue:

Also you can write this if you feel like:

	ifTrue: [2 inspect];
	and: [2 odd].

Of course, from pragmatic point of view, you won't probably need this stuff.
But if we can avoid useless sacrifices, let's avoid.

More information about the Pharo-project mailing list