delays in __sig__, a good idea?

Alex Russell <[email protected]> Sat, 28 Feb 2004 13:54:36 -0800
Newsgroups gmane.comp.windows.devel.netwindows
Organization netWindows.org
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey all,

so I've run across several situations with quick firing events which 
trigger expensive operations, and one of the things I normally wind 
up doing in situations like this is to use setTimeout to create a 
delayed exection. Here's the example:

__sig__.connect(domNode, "onresize", 
	null, "somethingExpensiveWithDelay");

function somethingExpensive(){
	// our expensive DOM operation happens here
}

var timerRef = null;

function somethingExpensiveWithDelay(delay){
	if(!delay){ 
		delay = 100; // sane for fast firing events
	}
	if(timerRef){
		clearTimeout(timerRef);
	}
	timerRef = setTimeout(function(){
		// could create closure. kinda of expensive.
		somethingExpensive();
	}, __util__.toInt(delay));
}

There are, of course, lots of useful variations on this basic setup, 
but you get the idea. Which brings us back to __sig__. It might be 
interesting (although I'm not sure if it's wise) to add another 
parameter to connect() that would take a delay and induce this 
"pre-emption" (for lack of a better word offhand) scenario.

The upside is that these scenarios would be shortened to something 
like:

__sig__.connect(callerObj, "callerFunc", 
			calleeObj, "calleeFunc",
			null, /* no default args, see yesterday's checkin notices */
			100 /*or some apprpriate delay */);

OTOH, this would induce slight delay into the call path for every 
dispatch since another conditional would be put in the fast-path. It 
is assumed that delayed functions will benefit enough from the 
short-cut ability to make the additional cost of closures and 
conditionals worthwhile. Another argument against this is the obtuse 
calling behavior (6 arguments to connect() does seem a bit 
long-winded).

Thoughts? 

Regards

- -- 
Alex Russell
[email protected]   BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAQQ4goV0dQ6uSmkYRAoQFAJ9wMYqr0IYm5fgIIK99UM9PFw9jjwCdHckQ
UlpV6dyhpJ/BgBssHx4raLM=
=VLMZ
-----END PGP SIGNATURE-----


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org