I can agree with you if the docs say the same as you: "The first call
is deferred until the interpreter is next idle."
"Next idle" - is the main point here.
But they say: "it will run as soon as the interpreter’s call stack is
empty."
In my example interpreter’s call stack is empty! And the code run not
in the way one can expect after *reading docs*.
T.J., we both understand that defer do no more then delay(0.01).
I think that docs should point out this, nothing more.
On Apr 2, 4:34 pm, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> Hi,
>
> > a1.defer(1);
> > a1(2);
>
> > Should produce '1' and then '2'. In real live it will produce '2' and
> > then '1'.
>
> No, it should produce "2" then "1" -- exactly as it does. The whole
> point of #defer is to defer execution of that call. The first call is
> deferred until the interpreter is next idle. It's not idle at that
> point (it's in the middle of executing those lines of code) and so it
> continues to the next thing it should do, which is to call `al`
> directly (not deferred). Why do you think it should be the other way
> around?
>
> -- T.J.
>
> On Apr 2, 11:30 am, mot <2mat...@gmail.com> wrote:
>
> > Thank's for theory.
>
> > Please look at my code example - the main question is about it.
>
> > Docs say: "Behaves much like window.setTimeout with a delay set to 0".
> > But should: "Behaves as window.setTimeout with a delay set to 0.01
> > second".
>
> > On Apr 1, 11:56 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
>
> > > Hi,
>
> > > > I looked at the Function#defer code, and there was nothing about
> > > > stack.
>
> > > The stack in question is in the JavaScript interpreter, not Prototype.
> > > In fact, it even says "...the interpreter's call stack." :-) (It's
> > > probably more a queue than a stack.)
>
> > > JavaScript in web browsers is single-threaded. That means that when
> > > code is *actively running*, no other code (for instance, scheduled via
> > > setTimeout or from an event handler) can run. Requests to run that
> > > code queue up in the interpreter until it's idle. That's the effect
> > > that Function#defer takes advantage of, by scheduling the code to run
> > > via setTimeout after a very brief delay.
>
> > > HTH,
> > > --
> > > T.J. Crowder
> > > Independent Software Consultant
> > > tj / crowder software / comwww.crowdersoftware.com
>
> > > On Apr 1, 7:36 am, mot <2mat...@gmail.com> wrote:
>
> > > > Hello all,
> > > > I use prototype library for several years and like it very much.
>
> > > > The question is about Function#defer. I used it in my work but never
> > > > looked under the hood.
> > > > The description says: "A “deferred” function will not run immediately;
> > > > rather, it will run as soon as the interpreter’s call stack is empty."
>
> > > > I looked at the Function#defer code, and there was nothing about
> > > > stack. All that defer do is delaying function run for 0.01 second. And
> > > > there is nothing about such behaviour in the docs.
>
> > > > According to docs, such code:
> > > > function a1(text) {
> > > > console.log(text);
>
> > > > }
>
> > > > a1.defer(1);
> > > > a1(2);
>
> > > > Should produce '1' and then '2'. In real live it will produce '2' and
> > > > then '1'.
>
> > > > I think API docs should be updated to help developers better
> > > > understand what defer really do.
--
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-scriptacul...@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.
