[Proto-Scripty] Re: Function#defer is not actually what it's description trying to say.
mot, Please submit a patch for the documentation. Thank you! Tobie -- 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.
[Proto-Scripty] Re: Function#defer is not actually what it's description trying to say.
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" 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" 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.
[Proto-Scripty] Re: Function#defer is not actually what it's description trying to say.
On Apr 2, 12:30 pm, mot <2mat...@gmail.com> wrote: > 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". That's equivalent in nearly all supported environments: calls to setTimeout with a delay below 10 ms are in fact executed after 10ms anyway. Tobie -- 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.
[Proto-Scripty] Re: Function#defer is not actually what it's description trying to say.
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" 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.
[Proto-Scripty] Re: Function#defer is not actually what it's description trying to say.
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" 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.
[Proto-Scripty] Re: Function#defer is not actually what it's description trying to say.
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 / com
www.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.
