ifNil:

Why oh why, if I use Class Browser to look at Object, select ifNil: instance
method, right click | References to: ifNil:

it comes back with 3 entries.

However if I use Dolphin Portal Screen, Browse | Containing Text... and
enter "ifNil:"

it comes back with quite a number of methods which use ifNil:

Its now made me think, should I not be trusting the "References to" result
sets in the browser?

"Sean Malloy" <[hidden email]> wrote in message
news:[hidden email]...
This is just speculation, but ifNil: is an optimized selector, as such it is
conceivable that the bytecodes are in-lined rather than a reference to the
message.  The three methods you found are not actually using ifNil:, rather
they contain a reference to the symbol #ifNil: .  All "References to" does
is find references to the symbol of the message.  If it is optimized away
then it will not be in the bytecode.  I suppose that one way around this
issue might be for the compiler to throw the optimized symbol in as some
kind of non-operation.  Perhaps doing so would have a negative performance
impact.

I think the best advice is just to watch out for special messages and be
aware that they are treated differently in certain situations.  Don't try to
override them, etc...  You can find a list in
STProgramNode<<optimizedSelectors .  There are not many, and they are fairly
common.  I suspect the slight confusion in these cases is worth the
performance improvement they yield.

Chris

> I think the best advice is just to watch out for special messages and be
> aware that they are treated differently in certain situations.  Don't try
> to override them, etc...  You can find a list in
> STProgramNode<<optimizedSelectors .  There are not many, and they are
> fairly common.  I suspect the slight confusion in these cases is worth the
> performance improvement they yield.

Sounds spot on.

So does that mean you can create your own optimised selectors?

Thanks Chris.

Regards,

Sean

Christopher J. Demers wrote:

>You can find a list in
> STProgramNode<<optimizedSelectors .

But note that that list isn't used by the compiler itself, so it /may/ not be
correct.  I /think/ it is mostly correct, but I wouldn't rely on it myself for
more than a good /indication/ of what the compiler is likely to "inline".
Indeed, I think it is incomplete in one sense -- expressions like x+1 and x-1
can also be inlined so that the resulting method has no reference to Symbol #+
or #-.

BTW, there's another version in AXInterfaceTypeAnalyzer class which is
apparently incomplete, even though it's part of Dolphin rather than the RB.
(It may be that it's correct for its purpose -- it's difficult to tell when
there's no method comment).

    -- chris

Sean Malloy wrote:

> So does that mean you can create your own optimised selectors?

Only if you write your own compiler (or do something similar).

    -- chris

> BTW, there's another version in AXInterfaceTypeAnalyzer class which is
> apparently incomplete, even though it's part of Dolphin rather than the
> RB.
> (It may be that it's correct for its purpose -- it's difficult to tell
> when
> there's no method comment).

Wow. Now that's dedication to studying the cass library :)

Andy, Blair, care to finally comment that class? ;P

Sean, Chris,

>>BTW, there's another version in AXInterfaceTypeAnalyzer class which is
>>apparently incomplete, even though it's part of Dolphin rather than the
>>RB.
>>(It may be that it's correct for its purpose -- it's difficult to tell
>>when
>>there's no method comment).
>
>
> Wow. Now that's dedication to studying the cass library :)

I'm impressed too.  But as a big believer in comments, I feel obligated
to point out that even if there were one, there would always be the risk
that it is incorrect.  Before the XP'ers point out the futility of
commenting, please note that comments at least tell us what the
developer(s) _thought_ they were trying to do, which is a big step over
guessing.


> Andy, Blair, care to finally comment that class? ;P

IMHO, it would be better to write the compiler in Smalltalk, so it too
would be under the watchful eye of the browsers.  It would also be a big
step toward getting one list of inlined methods.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

> as a big believer in comments, I feel obligated
> to point out that even if there were one, there would always be the risk
> that it is incorrect.

Oh sure, I just thought I'd take the chance to get this year's bitching about
comments out of the way early ;-)

    -- chris

Sean Malloy wrote:
> > BTW, there's another version in AXInterfaceTypeAnalyzer class which is
>>[...]
> Wow. Now that's dedication to studying the cass library :)

<grin/>

To be honest came across it by accident, browsing all references to #ifNil: --
it's first in the list...

    -- chris

P.S.  btw, Happy New Year everyone!  (meant to add that yesterday but forgot).

"Sean Malloy" <[hidden email]> wrote in message
news:[hidden email]...
Nope. I understand it well enough, and its not something I feel there is a
need to document :-).

I'm afraid the type-library analyser is pretty complicated, because the type
library API is very complicated, so if you want to understand it there is no
better documentation than live code you can debug alongside the API
documentation on MSDN.

In respect of the particular method in question, its supposed to be a list
of those optimised selectors that might possibly be generated from a
type-library, which is a long way of saying AXInterfaceTypeAnalyzer
class>>optimizedSelectors :-). It doesn't include any binary selectors since
"operators" are not valid names in a type library.

Regards

Blair

> Oh sure, I just thought I'd take the chance to get this year's bitching
> about
> comments out of the way early ;-)

22 hours into the new year. Is that a record?

Sean Malloy wrote:
> > Oh sure, I just thought I'd take the chance to get this year's bitching
> > about
> > comments out of the way early ;-)
>
> 22 hours into the new year. Is that a record?

11 hours 3 minutes, thank you very much.

(But I imagine that /someone/ in the Open-Source community has beaten it ;-)

    -- chris

"Christopher J. Demers" <[hidden email]> wrote in
message news:[hidden email]...
One could do this without any performance impact (other than inflating the
image a bit) by having the compiler include the optimised selectors in the
literal frame, even though they are not used. Actually the compiler already
does something similar with ##() (compile-time evaluated) expressions -
these are not run from the bytecodes, but the literals referenced in the
expression are added to the literal frame.

I must say my first thought on this was that it wouldn't be worth it, since
there are so many senders of the optimised selectors (which is one of the
reasons they are optimised of course) that there is really little point in
browsing for references to them. However, it would eliminate an
inconsistency and thereby remove a surprise for beginners, so it seems
worthwhile to investigate the actual cost. I used SmalltalkParser to build
parse trees for all the methods in my image, and from those one case
identify all the messages that are sent, optimised or not. I found about
1/5th of methods send one of the inlined selectors (#==, #ifTrue:[ifFalse:],
#ifNil:[:ifNotNil:], #and:, #or:, #isNil, #notNil, #yourself, #whileTrue[:],
#whileFalse[:], #repeat, #to:[by:]do:). Adding additional literal frame
entries to those methods in my image would consume just under 74Kb. This is
in an image in which the compiled method instances (not including the
bytecodes and the literal values themselves) consume nearly 3Mb, so as a
percentage the additional overhead is very low.

Is it worth it? Well I think it is, not because searching for senders of
#ifTrue: is particularly useful, but because it eliminates the surprise that
doing so does not work.

Regards

Blair

Blair McGlashan wrote:

> Is it worth it? Well I think it is, not because searching for senders of
> #ifTrue: is particularly useful, but because it eliminates the surprise
> that doing so does not work.

It would also make some kinds of reflective work easier.

Incidentally, if you made that change, then there's an argument for making a
similar arrangement for "special" selectors too.  That wouldn't make a
difference to the browsing operations in the UI, but it would make some kinds
of reflection /much/ faster since we wouldn't have to use a
BytecodeInterpretter to tell which of the specials were referred to.  I'm not
claiming that change is necessarily worthwhile, but I think it is worth
considering at the same time.

BTW (only marginally relevant): with today's machines, the limit on the number
of browsable methods (before the system prompts you "there are NNN methods, are
you sure you want to see them all?") is either too low, or unnecessary.
There's no great problem in opening a method browser on several thousand
methods, so why bother with the irritating[*] prompt first ?

    -- chris

([*] well, it irritates /me/ a bit, anyway -- but not enough that I've bothered
to remove it)