Hi Marcel,

On Thu, Dec 12, 2019 at 2:42 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Nicolas. :-)
>
> > What Eliot is saying is simply that we should call a spade a spade.
>
> Ah, right. I was wondering whether #sendsMessage: can make sense in
> CompiledCode or should be deprecated as Eliot suggested.
>

Ignore the classes below.  Let's look at Nicolas' definition, a message is
composed of a receiver, a selector and arguments. What this translates into
is that every message has a receiver expression, zero or more argument
expressions and a selector.  What that translates into in the bytecode of a
method is a sequence of bytecodes that compute a receiver, full,owed by
zero or more bytecode sequences, each of which computes an argument,
followed by a send bytecode that defines which selector to include in the
message.  What sendsSelector: does is look at those send bytecodes
and examines *only* the selector of the send. So sendsSelector: is what is
going on, both conceptually and in the bytecodee search.  If I constructed
a message, say Message selector: #at:put: arguments: #(1 2), I could
imagine a search function searcher sendsMessage: (Message selector:
#at:put: arguments: #(1 2)) that, e.g. by decompiling to a parse tree,
actually found all places in the system where at: 1 put: 2 is sent.  But
that's an entirely different thing from finding out where the message
selector at:put: is used in message sends.

There are a few places in the system where method, message nd selector are
confused and the wrong name used, for example,
ClassDescription>>methodsInCategory: answers the *selectors* in the
category:

Object methodsInCategory: #accessing #(#at: #at:modify: #at:put: #basicAt:
#basicAt:put: #basicSize #bindWithTemp: #enclosedSetElement
#ifNil:ifNotNilDo: #ifNotNilDo: #ifNotNilDo:ifNil: #in: #presenter
#readFromString: #size #yourself)

This should actually be called selectorsInCatefory: and  Object
methodsInCategory: #accessing should answer something like
{(Object>>#at: "a CompiledMethod(4092675)") . (Object>>#at:modify: "a
CompiledMethod(1648399)") . (Object>>#at:put: "a CompiledMethod(1177838)")
. (Object>>#basicAt: "a CompiledMethod(2919419)") . (Object>>#basicAt:put:
"a CompiledMethod(1073012)") . (Object>>#basicSize "a
CompiledMethod(1528204)") . (Object>>#bindWithTemp: "a
CompiledMethod(43943)") . (Object>>#enclosedSetElement "a
CompiledMethod(1573905)") . (Object>>#ifNil:ifNotNilDo: "a
CompiledMethod(2848834)") . (Object>>#ifNotNilDo: "a
CompiledMethod(751236)") . (Object>>#ifNotNilDo:ifNil: "a
CompiledMethod(1043558)") . (Object>>#in: "a CompiledMethod(3178194)") .
(Object>>#presenter "a CompiledMethod(2884658)") .
(Object>>#readFromString: "a CompiledMethod(3290973)") . (Object>>#size "a
CompiledMethod(414933)") . (Object>>#yourself "a CompiledMethod(2905289)")}

I'm anal/OCD/obnoxious enough to find this irritating ;-)  But to misquote
David Byrne, names don't do what I want them to ;-)

There are the following classes in Squeak:
>
> Symbol
> - can be a selector
>
> Message
> - only appears via MNU?
> - has no receiver stored because MNU callback has "self"
>
> MessageSend
> - like Message but no lookupClass
> - has receiver stored
> - alternative to simple BlockClosure such as [:arg | object foo: arg]
>
> CompiledCode (or CompiledMethod)
> - has all the instructions
>
> ***
>
> Having a look at SystemNavigation >> #allSentMessagesWithout:, I wondered
> how to distinguish "symbol" from "selector" ... and there is also
> "messages" in the text. Sigh. ... some confusion going on there. :-)
>
> ... MethodFinder >> #findMessage ... then better called #findSelector ?!
> ... :-)
>
> Best,
> Marcel
>
> Am 12.12.2019 11:27:49 schrieb Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
> Hi Marcel, of course you already know all this :)
> a message is composed of a receiver, a selector and arguments.
> a (Compiled)Method holds the instructions to be executed in response to a
> message.
> The methods are stored by object class (and superclasses...) in
> methodDictionary.
> In response to a message, the appropriate method is selected by the
> receiver by looking up for the message selector in methodDictionary.
> The instructions consist mostly of pushing/popping objects between the
> stack and object slots or method args/temps, and sending messages.
>
> What Eliot is saying is simply that we should call a spade a spade.
> So one could expect (self sendMessage: aMessage), (self sendSelector:
> aSelector), but not (self sendMessage: aSelector) nor (self sendSelector:
> aMessage).
>
> Le jeu. 12 déc. 2019 à 09:10, Marcel Taeumel <marcel.taeumel at hpi.de> a
> écrit :
>
>> Hi Eliot,
>>
>> how would you define selector, message, (message) send, and method? It
>> seems like a "message" is a very high-level concept. Selectors and methods
>> seem to be more on the implementation side and thus the right names to use
>> for such reflection over compiled code.
>>
>> Project >> #addDeferredUIMessage:
>> CompiledCode >> #abstractBytecodeMessageAt:
>> SystemNavigation >> #allSentMessages
>> ...
>>
>> Best,
>> Marcel
>>
>> Am 11.12.2019 20:50:30 schrieb commits at source.squeak.org <
>> commits at source.squeak.org>:
>> A new version of Kernel was added to project The Inbox:
>> http://source.squeak.org/inbox/Kernel-eem.1285.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Kernel-eem.1285
>> Author: eem
>> Time: 11 December 2019, 11:50:19.928718 am
>> UUID: 3dce70bd-9166-47fe-a86f-22456db9845a
>> Ancestors: Kernel-mt.1284
>>
>> Commit my own take on sendsSelector: vs sendsMessage:, and selectorsDo:
>> vs messagesDo:. IMNERHO sendsMessage: messagesDo: are *wrong*!! :-) c.f.
>> Behavior>>selectorsDo:
>>
>> =============== Diff against Kernel-mt.1284 ===============
>>
>> Item was changed:
>> ----- Method: CompiledCode>>messagesDo: (in category 'scanning') -----
>> messagesDo: workBlock
>> + "Evaluate aBlock with all the message selectors sent by me. Duplicate
>> seletors are possible."
>> - "Evaluate aBlock with all the message selectors sent by me. Duplicate
>> sends possible."
>>
>> + "If anything should be deprecated it is messagesDo:; it can be an
>> extension in AST/Refactoring.
>> + This method enumerates over selectors, not messages. c.f.
>> Behavior>>selectorsDo: etc"
>> + ^self selectorsDo: workBlock!
>> - | scanner selector |
>> - self isQuick ifTrue: [^ self].
>> -
>> - self codeLiteralsDo: [:compiledCode |
>> - scanner := InstructionStream on: compiledCode.
>> - scanner scanFor: [ :x |
>> - (selector := scanner selectorToSendOrSelf) == scanner
>> - ifFalse: [workBlock value: selector].
>> - false "keep scanning" ] ].!
>>
>> Item was added:
>> + ----- Method: CompiledCode>>selectorsDo: (in category 'scanning') -----
>> + selectorsDo: workBlock
>> + "Evaluate aBlock with all the message selectors sent by me. Duplicate
>> seletors are possible."
>> +
>> + self isQuick ifTrue: [^self].
>> +
>> + self codeLiteralsDo:
>> + [:compiledCode | | scanner |
>> + (scanner := InstructionStream on: compiledCode) scanFor:
>> + [:x| | selector |
>> + (selector := scanner selectorToSendOrSelf) ~~ scanner ifTrue:
>> + [workBlock value: selector].
>> + false "keep scanning"]]!
>>
>> Item was changed:
>> ----- Method: CompiledCode>>sendsMessage: (in category 'testing') -----
>> + sendsMessage: aSelector
>> + "eem: this should be deprecated. This method does not check if a method
>> sends a message;
>> + it checks if a method sends a message with a particular selector."
>> + self flag: #todo.
>> - sendsMessage: aSelector
>> -
>> self messagesDo: [:selector |
>> selector = aSelector ifTrue: [^ true]].
>> ^ false!
>>
>> Item was changed:
>> ----- Method: CompiledCode>>sendsSelector: (in category 'testing') -----
>> sendsSelector: aSelector
>> + "Answer if the receiver sends a message whose selector is aSelector."
>>
>> + self selectorsDo:
>> + [:selector | selector = aSelector ifTrue: [^true]].
>> + ^false!
>> - self flag: #todo. "mt: Deprecate? AST/Refactoring project needs it..."
>> - ^ self sendsMessage: aSelector!
>>
>>
>>
>>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191212/b0944dd9/attachment-0001.html>