Get rid of an object

Hello all,

  Thanks for the comments, they're helpful.

  When creating and testing objects in the Workspace, what is the
procedure for getting rid of any ?  Is there a need to do so ?  Can
objects lay there around without ever being destroyed, their creation
(eg. the text that created them) erased from the Workspace.  Can
created objects linger in the image endlessly ?  I presume that while
they are still holding data they won't be grabage-collected isn't it ?

Al
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Le Lundi, 1 Février 2010 19:39:06 -0500,
lanas <[hidden email]> a écrit :

>   When creating and testing objects in the Workspace, what is the
> procedure for getting rid of any ?  

I noticed that if I create the following and inspect it:

myCar := Car new.
myCar setCompany: 'Renault'.
myCar addEngine: 'Renault V4'.
myCar addDriveTrain: 'Renault DriveTrain'.

myCar will have these variables set.

Now, if I 'do it' once more on the first line the inspect window will
still show the same variables being set.  If I open another inspect
window on myCar I get the new object, without any variables yet set.

So it looks like objects of the same name are considered separate
entities.  I'd have thought that perhaps doing a 'do it' on myCar a
second time would have re-initialized the first existing object.

If I create 25 myCar for various tests, then there'll be 25 myCar
objects laying around in the image ?  How to get rid of them ?

Al
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

>>>>> "lanas" == lanas  <[hidden email]> writes:

lanas> Now, if I 'do it' once more on the first line the inspect window will
lanas> still show the same variables being set.

It's inspecting the old object, yes.

lanas>   If I open another inspect window on myCar I get the new object,
lanas> without any variables yet set.

It's another object, distinct from the previous one.

lanas> So it looks like objects of the same name are considered separate
lanas> entities.

No, the first one no longer has a name.  The inspector has a reference
to it, though.

lanas>   I'd have thought that perhaps doing a 'do it' on myCar a
lanas> second time would have re-initialized the first existing object.

No.  You created a new car, then gave it the name "myCar" in the current
workspace, completely releasing any previous object that myCar might have
referenced.  The thing to get is that when you say:

    x := y

then any thing that was previously in x cannot be affected.  The assignment is
always performing a new binding to a new object.

lanas> If I create 25 myCar for various tests, then there'll be 25 myCar
lanas> objects laying around in the image ?  How to get rid of them ?

Garbage is collected constantly by a background process. You can force it, but
there's generally no need.  Your car bits will eventually be recycled bits. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

El lun, 01-02-2010 a las 19:45 -0500, lanas escribió:
No, the moment you inspect it (i) a certain code like the one you show,
the Inspector windows is holding a reference to the object being
inspected (and by transitivity, to the objects referenced by it).

If, with the inspect windows open, you save and close the image, the
object is persisted, that is, isn't garbage colected because there is a
reference to it.

If you, instead, close the inspector window, then the object created by
your code isn't referenced by anything (pay attention that the code you
show is just text characters and not an object. The object is created
after the do it compiles it and *evaluates* it) so the object is garbage
collected. So if you save the image, the image will not have the object
persisted.

the same if you create hundred thousand objects, store them in a
collection and the the collection is thrown away.

The key here is that someone else must reference them in order to
persist. The Garbage collector can detect cyclic references so that they
are also collected (i.e, objA references objB and objB references objA,
the both will be garbage collected).

If you want to persist some object you can use class variables, because
they are part of the class singleton and therefore persisted together
with the class. This is used often to create image-based persistency.

Cheers
>
> Al
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

--
Miguel Cobá
http://miguel.leugim.com.mx

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Hi lanas,

There are several aspects to your question that need answering.

First, the garbage collector will remove any object that is not referenced by another object.

Each time you doit in a workspace you will create a new object.
Each time you assign that object to a variable it will replace the old object in that variable. The old object may at this point have no more references. Then it will be garbage collected.

Second, in the workspace menu there is an item

"reset variables"

choosing this causes that workspace to forget all of the variable assignments it was remembering because of doits. Then they may have no other references and be garbage collected.

Thirdly, one of my favorite styles of programming is to save my current work in projects. This saves code, morphs, browsers that are associated with my project. Later I load them back in to a fresh image. The context is that I am trying to always run the project in a fresh environment to assure against contamination from other work. Or to insure that the project works in a fresh system update. In this context it is wise to clean up my project before I save it. That way it has the best chance of reloading over an externally changing system environment.

So I have a big red button. In it I put the following mouse up code:

(SystemWindow windowsIn: World satisfying: [:w | w model canDiscardEdits and: [ w model notNil ] ])
                do: [:w | w delete] .

World submorphsDo: [:each |
        each model class = Workspace ifTrue: [ each model initializeBindings ]  ] .

The first part removes any browsers etc that I am finished with.
The second resets all my workspace variables. That way I don't save my temporary references. This is what you were concerned with.

For the button I use a starmorph reshaped into a hexagon and recolored to be red. The red halo menu>extras>addMouseUpAction allows me to place the action into the star.

In the USA a red hexagonal sign is the symbol for a stop sign. I make the button look like that so I remember to think twice before pressing it. But if I am about to save a project I want things sparse and clean.

hth,

Yours in curiosity and service, --Jerome Peace


--- On Mon, 2/1/10, lanas <[hidden email]> wrote:



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners