Ok. I see you're more or less married to your solution. Just thought I'd
offer up a proven to work, generic, extendable, scalable solution for anyone
interested. The coupling I was talking about was the fact that, as I
mentioned, you are making the user wait for N objects to dispose when they
close that tooltip (which could be a multi-step wizard or other dialog)...
fine for trivial things, but not fine if you care to account for arbitrarily
complex operations (which is what I mean by making something scalable) and
still offer a responsive experience to the end user. I've used something
like what you have... and have run into the problem.
Sorry, I don't have time to try to prove its merits by rewriting your stuff.
You are more than welcome to do so though... I already know how well it
works. You're right in your descriptions about how children should also be
disposed automatically. Simply extend a GC class to handle this (and you can
guess, yes I have done this as well).
I've been down your current path... solved it generically, and it works as
advertised (i.e. makes your application more responsive while managing
memory/resource deallocation issues)... was just offering some of that
learning to the community. Moreover, this is just good old fashion object
oriented application design principles translated into a new environment (
i.e. design generically, and seperate concerns and processes wherever
possible).
Javascript's built in GC... this is fine for pages designed to be short
lived, not so great for arbitrarily long running apps on a single page.
Asynchronicity, in this case, works beautifully (if you run into problems
here, then you need to rewrite your dispose methods - they shouldn't depend
on a deterministic execution). Absolutely, I wish we had true threading in
js. You're right (which I also said in my original post) that it's merely
interruption based. But the result is that the application appears to be
much more responsive to the user (due to both the memory deallocation and
also to the asynch operation). And this effect is the only one that matters.
The GC's frequency can also be tuned to achieve your desired balance... and
different levels of GC can be delegated to different GC instances, with
differing specialties and frequencies if needed (there's the extensibility
aspect).
As with any of my stuff... use it or don't use it :-)
Typo Fix to Original Code: I forgot to include passing the subclass's
frequency to the superclass constructor... subclass should be written
actually as follows:
/**
* DisposableGC is a very basic specialized subclass of the GCBase class.
* Its purpose is to handle the disposing of object resources
* from memory asynchronously in the background so-as not to
* impede application performance.
* @extends {RWG.GarbageCollection.GCBase}
*/
RWG.GarbageCollection.DisposableGC = Class.create();
RWG.GarbageCollection.DisposableGC.prototype =
{
/**
* @constructor
*/
initialize: function()
{
//cache the superclass
this.base = new RWG.GarbageCollection.GCBase(arguments.length > 0 ?
arguments[0] : null);
//inherit
Object.extend(this, this.base);
//override
this.cleanup = function(obj)
{
if (obj.dispose && typeof obj.dispose == "function")
obj.dispose();
};
}
};
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
