state - Purely functional feedback supression? -

state - Purely functional feedback supression? -

i have problem can solve reasonably easy classic imperative programming using state: i'm writing co-browsing app shares url's between several nodes. programme has module communication phone call link , browser handling phone call browser. when url arrives in link utilize browser module tell actual web browser start loading url.

the actual browser trigger navigation detection incoming url has started load, , hence presented candidate sending other side. must avoided, since create infinite loop of link-following same url, along line of next (very conceptualized) pseudo-code (it's javascript, please consider irrelevant implementation detail):

actualwebbrowser.urllisten.goturl(function(url) { // browser delivered url browser.process(url); }); link.receivedanurl(function(url) { actualwebbrowser.loadurl(url); // trigger above listener });

what did first wast store every incoming url in browser , eat url when arrives, remove 'received' list in browser, along lines of this:

browser.recents = {} // <--- mutable state browser.recentsexpiry = 40000; browser.dosend = function(url) { = (new date).gettime(); link.sendurl(url); // <-- url goes out on network // side-effect, mutating module state, clumsy clean mechanism :( browser.recents[url] = now; settimeout(function() { delete browser.recents[url] }, browser.recentsexpiry); homecoming true; } browser.process = function(url) { if(/* sanity checks on `url`*/) { = (new date).gettime(); var duplicate = browser.recents[url]; if(! duplicate) homecoming browser.dosend(url); if((now - duplicate_t) > browser.recentsexpiry) { homecoming browser.dosend(url); } homecoming false; } }

it works i'm bit disappointed solution because of habitual utilize of mutable state in browser. there "better way (tm)" using immutable info structures/functional programming or situation this?

a more functional approach handling long-lived state utilize parameter recursive function, , have 1 execution of function responsible handling single "action" of kind, calling 1 time again new state.

f#'s mailboxprocessor 1 illustration of kind of approach. depend on having processing happen on independent thread isn't same event-driven style of code.

as identify, settimeout in code complicates state management. 1 way simplify out instead have browser.process filter out timed-out urls before else. eliminate need timeout check on specific url processing.

even if can't eliminate mutable state code entirely, should think scope , lifetime of state.

for illustration might want multiple independent browsers? if should think how recents set can encapsulated belong single browser, don't collisions. if don't need multiple ones actual application, might help testability.

there various ways might maintain state private specific browser, depending in part on features language has available. illustration in language objects natural way create private fellow member of browser object.

functional-programming state stateless