Thank you T.J for the detailed answer, really helps.

In regards to what I'm trying to remove from memory I was referring to
the instance of the class. I can't imagine trying dynamically to get
rid of the class dynamically, when I could just remove it from my js
file if I don't need it.
This leads to another question. I have seen popups being implemented
where every time you rollover a link it creates a new instance of the
class. This just seems like a huge overhead to me. One implementation
was each time you rollover an anchor tag it creates a div below it
with the popup ( I think in their case it was a tooltip, similar ).
Then when you rollout of the anchor tag it removes the div and I would
imagine removes the reference in the js file to the newly created
popup.
For example in a seperate js file you might have rollover code on a
bunch of FAQ questions that every time the user rollsover the element
it creates a new popup in a name space of say

//pseudo-code
  app.popups  = appFunctionality
{

this.popup;

Rollover : function{
  this.popup = new Popup();
}

Rollout :function{
  this.popup.remove();
}

destroy: function{
}
  this.popup = undefined;
}


So the above namespace keeps my methods and variables in the
appFunctionality object from polluting the global space

This all seems fine to me as the element in the html markup only lasts
the duration of the rollover event. When rollout happens it gets
removed. Then on the js side the instance also gets removed.
Sorry for the long approach to this question but would it not be
better to create one instance of the popup at the start of your js
application and have that in it's own namespace. This way when you do
a rollover on an anchor it calls a show or hide method inside the
Popup class instead of constantly re-creating instances of the popup.
In the html you just dynamically add a div on the body that's display
hidden and then show on the rollover and hide on the rollout. Content
inside the popup can be changed based on what anchor tag you are over.
This way your not creating instances everytime and having to worry
about garbage collection.

Am I correct in thinking the above approach is less taxing on
everything.

Thanks again for the help in understanding GB collection.

On Aug 24, 3:36 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> Hi,
>
> It's unclear whether you're talking about removing the
> `namespace.Popup` *class* (well, constructor function -- JavaScript
> doesn't have classes), or removing the `popup` *instance* (object)
> that you've created for a specific popover.
>
> The short version:
>
> If you want to remove the instance you created in `rollever`, what
> you're doing is mostly fine although there's probably a bug in the
> quoted code. (You have an extra `var` in the line `var popup = new
> Popup()` which makes it shadow the variable you declare in the
> containing scope; as a result, it's eligible for GC as soon as
> `rollever` returns. Probably just a typo in the quick pseudo-code.)
>
> The long version:
>
> To release the memory associated with an object (or a primitive, for
> that matter), all you do is make sure nothing is referring to it
> anymore. JavaScript is a garbage-collected language, you don't release
> memory explicitly. You just make sure that nothing refers to the thing
> you want to get rid of, and eventually the garbage collector will
> notice that it's unreferenced and will remove it from memory. (When
> and how it does this is entirely up to the JavaScript implementation,
> some implementations are quite lazy, others are more pro-active.)
>
> You do that in one of four ways:
>
> 1. If the thing is referenced from a `var` (`var popup = new
> Popup();`), assign `undefined` to the `var` (`null` is also fine as
> you've done in `rollout`). I use `undefined` because it's symmetrical:
> `undefined` is the value a `var` has before you assign anything to it,
> so it makes sense to me that to "clear" it I put it back in that same
> state). But you see `null` used a lot, probably because it's short and
> easy to type and similar to the null concept in other languages, and
> there's nothing wrong with it if you don't obsess about symmetry like
> I do.
>
> 2. If the thing is a property on an object and you're done with the
> property, either A) assign `undefined` (or `null`) to the property
> (the object will still have the property but the property's value will
> be `undefined` [or `null`]), or B) completely remove the property from
> the object via `delete` (the object will no longer have the property
> at all). `delete` looks like this:
>
> delete foo.bar;
> // or
> delete foo["bar"]; // the string can be a literal, or any expression
> resulting in a string
>
> (Important: `delete` removes a property from an object. It has
> *nothing* to do with memory management, except as a side-effect -- if
> the property being removed was the last thing to reference something.
> It is nothing whatsoever like `delete` in C++ or some other
> languages.)
>
> 3. If the thing is a property on an object (like your `Popup` property
> on your `namespace` object), if you're done with the object as a
> whole, just release the object as a whole. Anything the object's
> properties referred to will get cleaned up if those are the only
> remaining references. E.g., when releasing `namespace`, you don't have
> to go through releasing all of its properties first.
>
> 4. If it's referenced from a `var` within a function, and you don't
> create any closures[1] (functions) within the function, just let the
> function return. If that `var` is the only thing referring to the
> thing you're trying to release, the reference will get cleaned up when
> the `var` is. (JavaScript nerds like me will point out that this is
> the same as #3 above, because behind the scenes, `var`s in functions
> are actually properties of an object that gets cleaned up when the
> function returns unless a closure has a reference to it.)
>
> Mind you, depending on what `Popup` does, you may not need to keep a
> copy of the instance at all. If it hooks up handlers to events or
> something, those references will keep it in memory until you unhook
> it.
>
> [1]http://blog.niftysnippets.org/2008/02/closures-are-not-complicated.html
>
> FWIW,
> --
> T.J. Crowder
> Independent Software Engineer
> tj / crowder software / com
> www / crowder software / com
>
> On Aug 23, 6:56 pm, chapster <emurra...@gmail.com> wrote:
>
>
>
>
>
>
>
> > When I create a class like example below. How would I remove a class
> > so its not in memory.
>
> > namespace.Popup = Class.create(
> > {
> >   initialize: function(params){
> >     ...
> >   },
>
> >   show:function(){
> >     // create or show
> >   }
>
> > });
>
> > I was thinking of creating this at the start of my application and
> > just hiding and showing the popup which will be a div that will be
> > passed into the popup class as a container.
>
> > In other languages I have called the class everytime a user rolls over
> > an element like below.
>
> > //pseudo code
>
> > var popup;
>
> > function rollever(){
> >    var popup = new Popup();
> >     popup.show();
>
> > }
>
> > function rollout(){
> >   if (popup) popup = null;
>
> > }
>
> > How would you remove a class like above in prototype.

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to