On 21.07.2007, at 05:55, Paul D. Fernhout wrote:

Once I modified a commercial Smalltalk so that "senders" showed all
methods which referenced the symbol with the same name. It was fairly
trivial to do, though I forget the details of how; it's been so long.


This is standard Squeak behavior. "Senders of" just iterates the literal dictionary of all methods. This thus will find all symbols written in a method. There
is a commonly used pattern build on top of this: if you want to remember
a place in the code to finish later, you can just add a

        self flag: #TODO

searching for senders of #TODO will send show this methods. (In Squeak,
you can see a use of this when searching for "bob").

I think searching all literals for "senders of" is standard Smalltalk behavior. Squeak enhanced this, it searches even inside nested literals like # (hello). This is quite a nice addition, as it is what you naively expect after having understood that "senders of" is in real a "literal symbols referenced from a method".

What Ted suggests is to use a special "selector name" object (or an object encodig
Selector + Arguments) instead of symbols for #perform and then search
*the complete system* for this on "senders of". This them will catch Selectors that
are not referenced from a method, but stored in an iVar in some object.

For Squeak, this would mean that this would be not allowes:

        self perform: #hallo

but this instead:

        sel := Selector named: #hallo.
        self perform:  sel.

The big question is how you would force people to never store the symbol and generate the Selector on demand? I think that if someone would not like this idea, he would just define a

        myPerform: aSymbol

                ^self perform: aSymbol asSelector

which then would defeat the whole scheme....

        Marcus

--
Marcus Denker  --  [EMAIL PROTECTED]
http://www.iam.unibe.ch/~denker



Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Reply via email to