Block source - a question

Hello all,

BACKGROUND
============
I noticed that I've been capturing blocks in STB streams, and would rather
not do so.  The main offender turns out to be fairly systematic.  The most
commonly captured block looks like [ :anObject | anObject displayString ];
the exceptional cases turn out to look like
[ :anObject | anObject time24 ].  Type converters might a better long-term
choice, but for now, I would be fairly happy replacing these blocks with
appropriate Message instances.  Something along the lines of aBlock method
getSource seemed a good starting point.  It turns out that the in-filed
objects can be distinguished by looking at aBlock method selector which is
either #initialize or #timeStamp:*.  At some point, I would back up all
offending files and then create a converted set.  Problem solved (I
hope<g>).


QUESTION
========
The interesting part is what happened when I tried to experiment with this
in a workspace.  Evaluating

( [ :anObject | anObject displayString ] method getSource )
  indexOfSubCollection:'time24'

gives a non-zero result.  A little debugging reveals that the entire
expression is part of the source.  Mostly out of curiosity, why does that
happen?

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:ae4ei5$v9m$[hidden email]...
Dolphin (at present) uses the original Smalltalk-80 design to represente
blocks, so they are not independently compiled units but just references
into the "home" method.

It is relatively easy to locate the start of a block's source in the home
method by mapping its startIP back using the IP to text range map that the
compiler provides for the debugger, but not quite so easy to find the end.
The easiest solution would be to run the expression through the RB compiler
can provide everything you need:

    (SmalltalkParser parseExpression: '[:anObject | anObject
displayString]') "=> StBlockNode(etc)"

You could then use the RB's parse tree matching to match those blocks of the
form: '[:`@arg | `@arg displayString]' (I'm sure I haven't got that right,
the syntax just seems to elude me - I have the same problem with regular
expressions). Maybe the rewrite engine could even do it all for you!

Regards

Blair

Blair,

> Dolphin (at present) uses the original Smalltalk-80 design to represente
> blocks, so they are not independently compiled units but just references
> into the "home" method.

I had wondered about that - it almost even makes sense to me now :)


> The easiest solution would be to run the expression through the RB
compiler
> can provide everything you need:
>
>     (SmalltalkParser parseExpression: '[:anObject | anObject
> displayString]') "=> StBlockNode(etc)"
>
> You could then use the RB's parse tree matching to match those blocks of
the
> form: '[:`@arg | `@arg displayString]' (I'm sure I haven't got that right,
> the syntax just seems to elude me - I have the same problem with regular
> expressions). Maybe the rewrite engine could even do it all for you!

So far, it's been enough just to know the method involved, but, I've since
uncovered another situation that might require the big guns, or would at
least benefit from parsing over assuming too much.

Thanks!

Bill

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

Bill Schwab <[hidden email]> wrote in message
news:ae4ei5$v9m$[hidden email]...
> BACKGROUND
> ============
> I noticed that I've been capturing blocks in STB streams, and would rather
> not do so.  The main offender turns out to be fairly systematic.  The most
> commonly captured block looks like [ :anObject | anObject displayString ];
> the exceptional cases turn out to look like
> [ :anObject | anObject time24 ].  Type converters might a better long-term
> choice, but for now, I would be fairly happy replacing these blocks with
> appropriate Message instances.  Something along the lines of aBlock method
...

This may be tangential.  I did not like using blocks so often for simple
things like this either.  I had heard about making a symbol work like a
block a while ago, but was hesitant to do it.  After working on a ListView
with lots of columns I finally decided to "just do it".  I added this method
to Symbol:

value: receiverObject

 "cdemers - 12/5/2001 This is so we can use symbols like blocks when only
one method send is needed."
 ^receiverObject perform: self.

I am not sure if this is considered "evil" but it sure saves some typing,
simplifies code, and avoids the creation of lots of blocks.  I think it
might be cool if the base system had a method like this (however purists
might object).

Chris

I made this change a long time ago in VisualAge and use it extensively
there.  When I pass a parameter that can either be a block or a symbol, I
call it an "action".  I also implemented the #value:value: type methods.

So far, it hasn't bit me in any way -

jlo

"Christopher J. Demers" <[hidden email]> wrote in
message news:ae5j1j$48aku$[hidden email]...
> Bill Schwab <[hidden email]> wrote in message
> news:ae4ei5$v9m$[hidden email]...
> > BACKGROUND
> > ============
> > I noticed that I've been capturing blocks in STB streams, and would
rather
> > not do so.  The main offender turns out to be fairly systematic.  The
most
> > commonly captured block looks like [ :anObject | anObject
displayString ];
> > the exceptional cases turn out to look like
> > [ :anObject | anObject time24 ].  Type converters might a better
long-term
> > choice, but for now, I would be fairly happy replacing these blocks with
> > appropriate Message instances.  Something along the lines of aBlock
method
> ...
>
> This may be tangential.  I did not like using blocks so often for simple
> things like this either.  I had heard about making a symbol work like a
> block a while ago, but was hesitant to do it.  After working on a ListView
> with lots of columns I finally decided to "just do it".  I added this
method