Objects interact with each other by sending messages, although you can get the sender by using reflection (thisContext sender), it is not a common practice to do so. So if you need another object to know the sender (or any other object) you simply pass it as a parameter. So modifying your example, and making the syntax actually work it would be: self property: ObjectClass new. self property caller: self. and then when you need to deal with that you can simply get a reference to that object and send it a message to do something: self property caller doSomething. You can also have something like self property: (ObjectClass for: self) In that case the #for: message is received by "ObjectClass class", which you can think of as if it were a Factory or a "static" method (it is not! it is much more powerful than that). ObjectClass class>>#for: callerObject ^self new setCaller: callerObject; yourself And that's it, you have an instance of ObjectClass that you initialized by sending #for: instead of #new (internally it ended up calling #new, but from the outside it was just a message send). And for the most part that's Smalltalk: Objects and messages. Regards! Esteban A. Maringolo On Wed, Jun 17, 2020 at 6:19 PM Russ Whaley <whaley.russ@gmail.com> wrote:
I find myself, over and over, creating a & storing q new object in an instVar, then storing (my)self on that object - so I can have easy access to the 'object that created me.'
<what I do now...>
self instVar := NewClass new.
self instVar callingObject: self.
"where these call the same messages"
self myMessage.
self instVar callingObject myMessage.
<is there a way to...>
self instVar := NewClass new.
self instVar objectWhoCreatedMe myMessage.
"I know there is a 'thisContext sender' - but is there a 'who created me' concept?"
Ultimately, there is no real overhead to storing (my)self on a new object, I guess, but as I'm developing and testing, I tend to have a whole lot of 'stranded objects' I have to remove manually.
Thoughts?
Thanks! -- Russ Whaley whaley.russ@gmail.com