a simple question (I think)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

a simple question (I think)

Russ Whaley
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: a simple question (I think)

Esteban A. Maringolo
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 <[hidden email]> 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
> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: a simple question (I think)

Richard O'Keefe
I have a strong dislike for incompletely initialised objects.
So I would do it like this:

   myInstVar := TheDependentClass newFor: self.

(together with any other essential information as parameters).
In my Smalltalk system it would look like this:

  Whatever subclass: #TheDependentClass
    instanceConstantNames: 'owner'
    ...
    class methods for: 'instance creation'
      newFor: owner
        ^(self basicNew) pvtOwner: owner; yourself

    methods for: 'initialising'
      pvtOwner: anObject
        super pvtPostNew.
        owner := anObject.

Private access to methods with a 'pvt' prefix is enforced.
Instance constants can only be set in private methods.
There's an additional wrinkle that makes it a run time
error to call TheDependentClass new, so that you cannot get
an incompletely initialised object.

In any Smalltalk you can follow similar conventions even if
they are not enforced.

Of course if you don't mind incompletely initialised objects,
nothing stops you writing code that allows them.  The question
is whether you want to be able to trust the 'owner' field or
not.

On Thu, 18 Jun 2020 at 09:46, Esteban Maringolo <[hidden email]> wrote:
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 <[hidden email]> 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
> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: a simple question (I think)

Russ Whaley
Thank you both for your insights. I’ve done the newFor: style many times, but where it falls short is when I read in a STON object. No worries, I was just wondering if there was something cool like “what object am I sitting on?”... I looked through Context and the client message will be helpful to me in other areas. I’m always eager to learn. Thank you very much for being willing to teach. 

Thanks!
Russ

On Wed, Jun 17, 2020 at 9:05 PM Richard O'Keefe <[hidden email]> wrote:
I have a strong dislike for incompletely initialised objects.
So I would do it like this:

   myInstVar := TheDependentClass newFor: self.

(together with any other essential information as parameters).
In my Smalltalk system it would look like this:

  Whatever subclass: #TheDependentClass
    instanceConstantNames: 'owner'
    ...
    class methods for: 'instance creation'
      newFor: owner
        ^(self basicNew) pvtOwner: owner; yourself

    methods for: 'initialising'
      pvtOwner: anObject
        super pvtPostNew.
        owner := anObject.

Private access to methods with a 'pvt' prefix is enforced.
Instance constants can only be set in private methods.
There's an additional wrinkle that makes it a run time
error to call TheDependentClass new, so that you cannot get
an incompletely initialised object.

In any Smalltalk you can follow similar conventions even if
they are not enforced.

Of course if you don't mind incompletely initialised objects,
nothing stops you writing code that allows them.  The question
is whether you want to be able to trust the 'owner' field or
not.

On Thu, 18 Jun 2020 at 09:46, Esteban Maringolo <[hidden email]> wrote:
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 <[hidden email]> 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
> [hidden email]

--
Russ Whaley
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: a simple question (I think)

Stéphane Ducasse
as a general principle do not use thisContext. 


S. 

On 20 Jun 2020, at 01:12, Russ Whaley <[hidden email]> wrote:

Thank you both for your insights. I’ve done the newFor: style many times, but where it falls short is when I read in a STON object. No worries, I was just wondering if there was something cool like “what object am I sitting on?”... I looked through Context and the client message will be helpful to me in other areas. I’m always eager to learn. Thank you very much for being willing to teach. 

Thanks!
Russ

On Wed, Jun 17, 2020 at 9:05 PM Richard O'Keefe <[hidden email]> wrote:
I have a strong dislike for incompletely initialised objects.
So I would do it like this:

   myInstVar := TheDependentClass newFor: self.

(together with any other essential information as parameters).
In my Smalltalk system it would look like this:

  Whatever subclass: #TheDependentClass
    instanceConstantNames: 'owner'
    ...
    class methods for: 'instance creation'
      newFor: owner
        ^(self basicNew) pvtOwner: owner; yourself

    methods for: 'initialising'
      pvtOwner: anObject
        super pvtPostNew.
        owner := anObject.

Private access to methods with a 'pvt' prefix is enforced.
Instance constants can only be set in private methods.
There's an additional wrinkle that makes it a run time
error to call TheDependentClass new, so that you cannot get
an incompletely initialised object.

In any Smalltalk you can follow similar conventions even if
they are not enforced.

Of course if you don't mind incompletely initialised objects,
nothing stops you writing code that allows them.  The question
is whether you want to be able to trust the 'owner' field or
not.

On Thu, 18 Jun 2020 at 09:46, Esteban Maringolo <[hidden email]> wrote:
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 <[hidden email]> 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
> [hidden email]

--
Russ Whaley
[hidden email]

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

Reply | Threaded
Open this post in threaded view
|

Re: a simple question (I think)

Russ Whaley
Why? (question, not a challenge :) ) 

- I really only use it in a Logger class I developed that let’s me know at the time of logging, what method and class I’m in - ... write to the log... done. 

On Sat, Jun 20, 2020 at 3:08 AM Stéphane Ducasse <[hidden email]> wrote:
as a general principle do not use thisContext. 


S. 


On 20 Jun 2020, at 01:12, Russ Whaley <[hidden email]> wrote:

Thank you both for your insights. I’ve done the newFor: style many times, but where it falls short is when I read in a STON object. No worries, I was just wondering if there was something cool like “what object am I sitting on?”... I looked through Context and the client message will be helpful to me in other areas. I’m always eager to learn. Thank you very much for being willing to teach. 

Thanks!
Russ

On Wed, Jun 17, 2020 at 9:05 PM Richard O'Keefe <[hidden email]> wrote:
I have a strong dislike for incompletely initialised objects.
So I would do it like this:

   myInstVar := TheDependentClass newFor: self.

(together with any other essential information as parameters).
In my Smalltalk system it would look like this:

  Whatever subclass: #TheDependentClass
    instanceConstantNames: 'owner'
    ...
    class methods for: 'instance creation'
      newFor: owner
        ^(self basicNew) pvtOwner: owner; yourself

    methods for: 'initialising'
      pvtOwner: anObject
        super pvtPostNew.
        owner := anObject.

Private access to methods with a 'pvt' prefix is enforced.
Instance constants can only be set in private methods.
There's an additional wrinkle that makes it a run time
error to call TheDependentClass new, so that you cannot get
an incompletely initialised object.

In any Smalltalk you can follow similar conventions even if
they are not enforced.

Of course if you don't mind incompletely initialised objects,
nothing stops you writing code that allows them.  The question
is whether you want to be able to trust the 'owner' field or
not.

On Thu, 18 Jun 2020 at 09:46, Esteban Maringolo <[hidden email]> wrote:
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 <[hidden email]> 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
> [hidden email]

--
Russ Whaley
[hidden email]

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

--
Russ Whaley
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: a simple question (I think)

Richard Sargent
Administrator


On Sun, Jun 21, 2020, 14:54 Russ Whaley <[hidden email]> wrote:
Why? (question, not a challenge :) ) 

- I really only use it in a Logger class I developed that let’s me know at the time of logging, what method and class I’m in - ... write to the log... done. 

That's a reasonable use.

In general, you don't use it to derive meaning that your program relies on. Stack reporting is a good use. 
Your logging use is a degenerate case of stack reporting.


On Sat, Jun 20, 2020 at 3:08 AM Stéphane Ducasse <[hidden email]> wrote:
as a general principle do not use thisContext. 


S. 


On 20 Jun 2020, at 01:12, Russ Whaley <[hidden email]> wrote:

Thank you both for your insights. I’ve done the newFor: style many times, but where it falls short is when I read in a STON object. No worries, I was just wondering if there was something cool like “what object am I sitting on?”... I looked through Context and the client message will be helpful to me in other areas. I’m always eager to learn. Thank you very much for being willing to teach. 

Thanks!
Russ

On Wed, Jun 17, 2020 at 9:05 PM Richard O'Keefe <[hidden email]> wrote:
I have a strong dislike for incompletely initialised objects.
So I would do it like this:

   myInstVar := TheDependentClass newFor: self.

(together with any other essential information as parameters).
In my Smalltalk system it would look like this:

  Whatever subclass: #TheDependentClass
    instanceConstantNames: 'owner'
    ...
    class methods for: 'instance creation'
      newFor: owner
        ^(self basicNew) pvtOwner: owner; yourself

    methods for: 'initialising'
      pvtOwner: anObject
        super pvtPostNew.
        owner := anObject.

Private access to methods with a 'pvt' prefix is enforced.
Instance constants can only be set in private methods.
There's an additional wrinkle that makes it a run time
error to call TheDependentClass new, so that you cannot get
an incompletely initialised object.

In any Smalltalk you can follow similar conventions even if
they are not enforced.

Of course if you don't mind incompletely initialised objects,
nothing stops you writing code that allows them.  The question
is whether you want to be able to trust the 'owner' field or
not.

On Thu, 18 Jun 2020 at 09:46, Esteban Maringolo <[hidden email]> wrote:
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 <[hidden email]> 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
> [hidden email]

--
Russ Whaley
[hidden email]

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

--
Russ Whaley
[hidden email]