Franck Porcher, Docteur ès Sciences (Paris VI), Informatique théorique ---------------------------------------------------------------------- SMART Technologies Les solutions intelligentes ---------------------------------------------------------------------- Société de Services et d'Ingénierie en Informatique Solutions Open Source Linux & FreeBSD 1995-2008 : Premier fournisseur en Polynésie française
Tél: (689) 711 911 Email: fporcher(at)smartech(dot)pf Web: www(dot)smartech(dot)pf ---------------------------------------------------------------------- "You can analyze the past but you have to design the future." Ignacio Coloma wrote: >>>2) Ajax.Response objects >>>Instead, I envision a *single* Ajax.Response object per Ajax.Request, >>>to be updated as many times as necessary while the XHR progresses to >>>completion (readyState value). >>> >>> >>I know that every JavaScript implementation is single-threaded, >>but--theoretically--couldn't this lead to race conditions? (Eg. when >>Response instance changes while you're processing it) >> >>But if you spot places where you can reduce processing being done, >>optimization patches are always welcome. >> >> > >My humble opinion: > >I could store the response object elsewhere, and there is no real >reason to forbid me from doing so (I hate when frameworks reuse the >objects they handle to the developer). > > > Is this not the case with the XHR ; being updated by low level Core Javascript while handled by the developper through whatever 'onreadystatechange' callback ? As such, the "theoretical" race condition mentionned by Mislav is intrinsic, wether we use Prototype's actual higher level callback API, or the low level Core XHR. And yes I do too hate when frameworks reuse objects they handle to the user. But I reconcile here by considering a Prototype Ajax.Request as kind of a "temporal" object (as opposed to "snapshot" object), going through states in a *monotonic* way (readyState only increases). In this light, I (the user) expect the object to "evolve" (another way of saying that the framework updates it), and I monitor it until it reaches its final state. So it bothers me to get different Ajax.Response objects over time. I feel that it would be easier to "extract" instantaneous views of a "temporal long lived" Ajax response object (cloning operation), should the need arise, than to build a temporal view from various independant instantaneous response objects. A matter of taste ;-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
