is this info about #run:with:in: still correct (usable, I mean)

[kdabwl]

sorry if my RFI here misplaced; I´m attempting to use MethodMassage for my run:with:in: on aBlock approach;

is this info still correct (and usable): query on run:with:in:

[LinqLover]

Hey @kdabwl, sorry for the late reply! LLM outputs regarding Squeak/Smalltalk are very often hallucinated, and so is the conversation you shared. Squeak has not been having BlockContexts or blockCopy: for years. IRBuilder is not a class in current Squeak (maybe it belongs to an external package I don't know or to Pharo). What is the actual goal you want to achieve?

If you want to, you can do this:

BlockClosure compile: 'flushCache'.
BlockClosure compile: 'run: aSymbol with: arguments in: receiver
	^ self valueWithArguments: arguments'.
Object methodDict at: #foo put: [6*7].
Object methodDict at: #foo: put: [:x | x negated].
self foo. "--> 42"
self foo: 1. "--> -1"

Or:

BlockClosure compile: 'run: aSymbol with: arguments in: receiver
	^ self valueWithArguments: (arguments copyWithFirst: receiver)'.
Object methodDict at: #foo: put: [:x :y | x * y].
6 foo: 7. "--> 42"

Or if you really want:

BlockClosure compile: 'run: aSymbol with: arguments in: receiver
	self receiver: receiver.
	^ [self valueWithArguments: arguments]
		ensure: [self receiver: nil]'.
Object methodDict at: #foo: put: [:x | self * x].
6 foo: 7. "--> 42"

But that's not too Smalltalk-ish (implicit type conversion, not really clear what the receiver does). You can also check out this project: https://github.com/hpi-swa/MethodWrappers

HTH! Any other questions? :-)

[kdabwl]

Hello @LinqLover, thanks for the hints and examples; sorry I didn´t clear the LLM´s confusion (I know that Smalltalker LLM users / readers can transform on-the-flight ;-)
Yes, the case with <code>self receiver:</code> is what I intend, no worries about the <type> since implementor is not Object, and receiver class can only be member of (implementor class withAllSubclasses).
And thanks for the link to your project, will follow up on how my "thing" is already covered.
I intend to declare "private state of traits" as temp var in prototype methods, and "code transform" access to that temp var into inst var access (heavy [but easy] details omitted here); the blocks in the prototype method are then #run:with:in: as in your last example (on a shallowCopy which serves as "instantiation" of prototype); thanks again for confirming that it still "runs" in current VM (I had question marks on who/where has to do the #valuewith, very good to see that the prototyped blocks need no change); I´ll now wait for the release of "CompiledCodeTransformer" MethodMassage.

[LinqLover]

Interesting, thanks for sharing @kdabwl! The MethodMassage API is not too complicated, you could perhaps already figure it out by yourself today. :-)

Here's another idea for stateful traits (not yet tested):

TMyTrait>>pvtStates
	^ [EphemeronIdentityDictionary new] once

TMyTrait>>myAccessor

	^ self pvtStates at: self ifAbsent: [nil]

TMyTrait>>myAccessor: anObject

	^ self pvtStates at: self put: anObject

However, that state will be volatile if one recompiles a method. A more stable solution would be a global variable/a class variable in a helper class.

... but Eliot's idea of adding instance variables to the users of a trait might give a cleaner, and much faster solution.

[kdabwl]

Hello @LinqLover, you [implicitly] address the [most] unpleasant use case, that behavior is wanted to be inheritable but state is wanted only where it effectively does "action" (at the most specific level); imagine adding 'position' instVar to class definition of Sequenceable­Collection (traditional exemplary stream use case of Traits), which would needlessly "infect" existing instances; correct me but stateful Traits [your suggestion not meant], when demanding private 'position' state, would have to be applied to String and to Array (this I want to avoid, and your pvtStates sketch is a good idea).