The Inbox: Kernel-eem.1285.mcz
Locked
 
|
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! |
Re: The Inbox: Kernel-eem.1285.mcz
|
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
|
Re: The Inbox: Kernel-eem.1285.mcz
|
|
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 <[hidden email]> a écrit :
|
Re: The Inbox: Kernel-eem.1285.mcz
|
|
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. 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
|
Re: The Inbox: Kernel-eem.1285.mcz
|
|
Hi Marcel, On Thu, Dec 12, 2019 at 2:42 AM Marcel Taeumel <[hidden email]> wrote:
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 ;-)
_,,,^..^,,,_ best, Eliot |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |