Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #18663 > unrolled thread

Setting focus

Back to article view | Back to comp.lang.javascript

Contents

  Setting focus Tim Slattery <Slattery_T@bls.gov> - 2013-02-28 14:30 -0500
    Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-28 20:50 +0100
      Re: Setting focus Tim Slattery <Slattery_T@bls.gov> - 2013-02-28 16:05 -0500
        Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-28 22:17 +0100
          Re: Setting focus Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-02-28 23:16 +0100
            Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-02-28 23:36 +0100
              Re: Setting focus Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-03-01 08:21 +0100
                Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-01 13:10 +0100
            Re: Setting focus "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-02-28 23:37 +0100
              Re: Setting focus Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-03-01 08:18 +0100
                Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-01 13:12 +0100
                  Re: Setting focus Bernd Nawothnig <Bernd.Nawothnig@t-online.de> - 2013-03-02 15:16 +0100
          Re: Setting focus Scott Sauyet <scott.sauyet@gmail.com> - 2013-03-21 20:06 -0700
            Re: Setting focus Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-03-22 10:03 +0100
              Re: Setting focus Tim Slattery <Slattery_T@bls.gov> - 2013-03-22 08:53 -0400
                Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-23 15:09 +0100
              Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-23 15:07 +0100
                Re: Setting focus Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-03-24 12:38 +0100
                  Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-24 13:42 +0100
                    Re: Setting focus Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-03-24 13:54 +0100
            Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-23 15:04 +0100
              Re: Setting focus Scott Sauyet <scott.sauyet@gmail.com> - 2013-03-23 17:35 -0700
                Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-24 10:41 +0100
                  Re: Setting focus Scott Sauyet <scott.sauyet@gmail.com> - 2013-03-24 16:42 -0700
                    Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-30 14:27 +0100
                      Re: Setting focus Scott Sauyet <scott.sauyet@gmail.com> - 2013-03-30 09:25 -0700
                        Re: Setting focus Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-30 19:50 +0100
                          Re: Setting focus Scott Sauyet <scott.sauyet@gmail.com> - 2013-03-30 17:11 -0700
                Re: Setting focus Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-03-30 01:02 +0100
                  Re: Setting focus Scott Sauyet <scott.sauyet@gmail.com> - 2013-03-30 09:17 -0700
                    Re: Setting focus "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-03-30 17:55 +0100

Page 2 of 2 — ← Prev page 1 [2]

#18976

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Tim Slattery wrote:
>>> field = document.getElementById("newbox");
>>
>> var field = …
>>
>>> setTimeout("field.focus()", 50);
>>
>> var t = window.setTimeout(function () {
>> field.focus();
>> window.clearTimeout(t);
>> field = null;
>> t = null;
>> }, 50);
>>
>> That is, of course, also only a temporary workaround.
> 
> Of course, but if you're going down this path, why not something as
> simple as
> 
>     (function() {
>         var field = …;
>         window.setTimeout(function () {
>     field.focus();
>         }, 50);
>     }());

Because it is insufficient.
 
> Your code suggests of course that the function associated with the
> setTimeout call will live well beyond the time when it's fired,

“The function” (the Function instance) “will live” (may exist) “well beyond” 
(beyond) the time when it is “fired” (called).

> and so the properties in the related closure should be cleaned up.

_Variables_, not properties.

> I've never run across that.

I am not surprised.

> Do you have any demonstrations of it

Not at the moment.

> or references that discuss it?

Yes.

> I have my doubts because it seems to me that if it were the case, pages
> with heavy animations would often quickly overload the memory.

Not necessarily.

> But I'd love to hear more.

Closures are discussed in the FAQ Notes.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#18980

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:

>> Your code suggests of course that the function associated with the
>> setTimeout call will live well beyond the time when it's fired,
>
> “The function” (the Function instance) “will live” (may exist) “well beyond”
> (beyond) the time when it is “fired” (called).

Did you not understand what I said?  Did you think that others would
not?


>> and so the properties in the related closure should be cleaned up.
>
> _Variables_, not properties.

I'm not sure I agree with your correction, but I also don't think it's
the slightest bit relevant.


>> I've never run across that.
>
> I am not surprised.
>
>> Do you have any demonstrations of it
>
> Not at the moment.
>
>> or references that discuss it?
>
> Yes.

Would you please do me the honor of sharing such references?


>> I have my doubts because it seems to me that if it were the case, pages
>> with heavy animations would often quickly overload the memory.
>
> Not necessarily.

Of course not.  In fact, certain style animations would never use
`setTimeout` at all, choosing `setInterval` instead, and others would
only ever have reference to a single function even though it's been
registered with `setTimeout` many times.  But there are many
animations that were not written that way, and I don't recall issues
with memory consumption.  However I've never paid a great deal of
attention to animations, so it's certainly possible that I've just not
noticed it.



>> But I'd love to hear more.
>
> Closures are discussed in the FAQ Notes.

...as are many some other interesting topics.  I've read the excellent
Closure article several times over the years, and I certainly don't
recall any discussion of a need to manually clean up references to
functions passed to `setTimeout`.  I just went and double-checked, and
there is a section on the interaction of `setTimeout` with closures
(which I alluded to in the prior post), but the text does not suggest
that any clean-up is needed, nor is there any in the sample code.

I look forward to your references.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#18981

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> Your code suggests of course that the function associated with the
>>> setTimeout call will live well beyond the time when it's fired,
>>
>> “The function” (the Function instance) “will live” (may exist) “well
>> beyond” (beyond) the time when it is “fired” (called).
> 
> Did you not understand what I said?  Did you think that others would
> not?

You may have noticed that I try to avoid script-kiddie speak, and try to use 
correct and unambiguous wording.  For example, functions are not “fired”; 
they are called (to be exact, Function instances are called using the 
[[Call]] internal method).

>>> and so the properties in the related closure should be cleaned up.
>> _Variables_, not properties.
> 
> I'm not sure I agree with your correction,

Variables are not necessarily properties.  It depends on how you look at it, 
specifically which Edition of ECMAScript you are using as reference.

> but I also don't think it's the slightest bit relevant.

But it is.  Variables are tied to an execution context; properties are tied 
to objects.
 
>>> Do you have any […] references that discuss it?
>> Yes.
> 
> Would you please do me the honor of sharing such references?

Not again.

>>> I have my doubts because it seems to me that if it were the case, pages
>>> with heavy animations would often quickly overload the memory.
>>
>> Not necessarily.
> 
> Of course not.  In fact, certain style animations would never use
> `setTimeout` at all, choosing `setInterval` instead, and others would
> only ever have reference to a single function even though it's been
> registered with `setTimeout` many times.  But there are many
> animations that were not written that way, and I don't recall issues
> with memory consumption.  However I've never paid a great deal of
> attention to animations, so it's certainly possible that I've just not
> noticed it.

ISTM that your careless use of language is indicative of careless thinking.  
I find your arguments strewn with weasel words like “well beyond”, “heavy”, 
“quickly”, and so on, and with gaping defects in logic.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#18988

Thomas 'PointedEars' Lahn wrote:
>Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:
>>>> Your code suggests of course that the function associated with the
>>>> setTimeout call will live well beyond the time when it's fired,
>
>>> “The function” (the Function instance) “will live” (may exist) “well
>>> beyond” (beyond) the time when it is “fired” (called).
>
>> Did you not understand what I said?  Did you think that others would
>> not?
>
> You may have noticed that I try to avoid script-kiddie speak, and try to use
> correct and unambiguous wording.  For example, functions are not “fired”;
> they are called (to be exact, Function instances are called using the
> [[Call]] internal method).

So you aren't willing to give a yes-or-no answer to my questions?

The ECMAScript specification describes how to implement the language,
not how to talk about it.  In English discussions about programming,
"calling" and "firing" a function have closely related, but not
entirely identical meanings.  Both evoke the notion of invocation as
expressed by `[[Call]]`, but "firing" often also evokes the notion of
a singular event, something that can only happen once, whereas
"calling" tends to imply something that can be invoked repeatedly.

By using "fired", I was, in fact, using some of this association.
Certainly a function supplied as a parameter to `setTimeout` can be
invoked many times, but in many situations it is not.  Suggesting that
the function would live well beyond the time it was called meant to
me, and I apologize if this wasn't clear to you, that it wouldn't be
garbage collected.


>>>> and so the properties in the related closure should be cleaned up.
>>> _Variables_, not properties.
>
>> I'm not sure I agree with your correction,
>
> Variables are not necessarily properties.  It depends on how you look at it,
> specifically which Edition of ECMAScript you are using as reference.

So then, depending upon how you look at it, your correction was
unnecessary?



>> but I also don't think it's the slightest bit relevant.
>
> But it is.  Variables are tied to an execution context; properties are tied
> to objects.

So your idea of what terms I should use to discuss this -- even though
it was clear enough that you could determine exactly how you should
correct me -- is much more important than actually discussing the
basic idea under question?  Pathetic.



>>>> Do you have any […] references that discuss it?
>>> Yes.
>
>> Would you please do me the honor of sharing such references?
>
> Not again.

So you make a claim, then further claim that you have references that
support it, but refuse to provide those references.  You quibble about
my terminology rather than defend the notion you're promoting without
any evidence.  Why should anyone believe you?

I don't know if you've noticed the number of times over my three-and-a-
half years here that I've defended you as having an overall positive
impact on this group in spite of your obvious antisocial tendencies.
I think I'm done with that; it's becoming too hard for me to raise the
effort.



> [ ... ]
> ISTM that your careless use of language is indicative of careless thinking.
> I find your arguments strewn with weasel words like “well beyond”, “heavy”,
> “quickly”, and so on, and with gaping defects in logic.

And ISTM that whenever you find yourself unable to defend an idea that
you've been promoting, you resort to this sort of quibbling and ad
hominem attacks.  Those words are perhaps not as specific as you would
like, but that is not evidence of weaseling.  Now to claim to have
references to support one's position and still to refuse to share them
-- that sounds like weaseling.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#19057

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>>Scott Sauyet wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Scott Sauyet wrote:
>>>>> Your code suggests of course that the function associated with the
>>>>> setTimeout call will live well beyond the time when it's fired,
>>>>
>>>> “The function” (the Function instance) “will live” (may exist) “well
>>>> beyond” (beyond) the time when it is “fired” (called).
>>>
>>> Did you not understand what I said?  Did you think that others would
>>> not?
>>
>> You may have noticed that I try to avoid script-kiddie speak, and try to
>> use correct and unambiguous wording.  For example, functions are not
>> “fired”; they are called (to be exact, Function instances are called
>> using the [[Call]] internal method).
> 
> So you aren't willing to give a yes-or-no answer to my questions? […]

That is correct.  I will not fall for your *fallacies*.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#19059

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:

>>>> Did you not understand what I said?  Did you think that others would
>>>> not?
>
>>> You may have noticed that I try to avoid script-kiddie speak, and try to
>>> use correct and unambiguous wording.  For example, functions are not
>>> “fired”; they are called (to be exact, Function instances are called
>>> using the [[Call]] internal method).
>
>> So you aren't willing to give a yes-or-no answer to my questions? […]
>
> That is correct.  I will not fall for your *fallacies*.

That's what I thought.

Pathetic.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#19061

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Scott Sauyet wrote:
>>>>> Did you not understand what I said?  Did you think that others would
>>>>> not?
>>>> You may have noticed that I try to avoid script-kiddie speak, and try
>>>> to use correct and unambiguous wording.  For example, functions are not
>>>> “fired”; they are called (to be exact, Function instances are called
>>>> using the [[Call]] internal method).
>>> So you aren't willing to give a yes-or-no answer to my questions? […]
>> That is correct.  I will not fall for your *fallacies*.
> 
> That's what I thought.

Thank you.
 
> Pathetic.

No, it is wise not to fall for someone's fallacy, which in this case was 
yours: two false dichotomies.  Your next fallacy has been argumentum ad 
hominem.

HTH

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#19064

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Scott Sauyet wrote:
>>>>>> Did you not understand what I said?  Did you think that others would
>>>>>> not?
>>>>> You may have noticed that I try to avoid script-kiddie speak, and try
>>>>> to use correct and unambiguous wording.  For example, functions are not
>>>>> “fired”; they are called (to be exact, Function instances are called
>>>>> using the [[Call]] internal method).
>>>> So you aren't willing to give a yes-or-no answer to my questions? […]
>>> That is correct.  I will not fall for your *fallacies*.
>> That's what I thought.
> Thank you.

I'm surprised you are grateful that I find you unwilling to answer a
simple yes-no question, but if that's how you feel, fine.


>> Pathetic.
>
> No, it is wise not to fall for someone's fallacy, which in this case was
> yours: two false dichotomies.

I'm not sure what dichotomies you think I was proposing.  I simply
asked if you understood the intent of my statement, with the obvious
intent of implying that your correction was unnecessary.  And I
similarly asked if you thought my statement would have been
understandable to others.  A yes or no would have sufficed to each of
these questions.  Instead you continued trying to insist on the
correction you were making.


> Your next fallacy has been argumentum ad hominem.

If you're referring to this:

>> Pathetic.

then you're mistaken.  That is not any sort of logical fallacy at
all.  It is not part of any logical argument.  It is a plain old
insult.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#19055

Scott Sauyet <scott.sauyet@gmail.com> writes:

> [...] In fact, certain style animations would never use
> `setTimeout` at all,

Right. CSS transitions, animations, keyframes. Or, for scripting,
requestAnimationFrame.

> choosing `setInterval` instead,

Oh my.

[toc] | [prev] | [next] | [standalone]

#19058

Eric Bednarz wrote:
> Scott Sauyet writes:
>> [...] In fact, certain style animations would never use
>> `setTimeout` at all,
>
> Right. CSS transitions, animations, keyframes. Or, for scripting,
> requestAnimationFrame.
>
>> choosing `setInterval` instead,
>
> Oh my.

Please remember the context: a discussion about whether it was
necessary to clean up behind a `setTimeout`.  I was bringing a class
of animations into this as an example of code that often made heavy
uses of `setTimeout` often without doing the cleanup that Thomas
insisted was necessary.  I was not trying to list all the forms of
animation available.

Thomas claims to have evidence that he's unwilling to share that code
of this sort is necessary:

    var field = …

    var t = window.setTimeout(function () {
      field.focus();
      window.clearTimeout(t);
      field = null;
      t = null;
    }, 50);

and that my alternative is harmful:

    (function() {
        var field = …;
        window.setTimeout(function () {
            field.focus();
        }, 50);
    }());

I've never seen any evidence of that.  That's the context of these
discussion.  Animations are not really central to the point, just one
example.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#19060

Scott Sauyet wrote on 30 mrt 2013 in comp.lang.javascript:

> Eric Bednarz wrote:
>> Scott Sauyet writes:
>>> [...] In fact, certain style animations would never use
>>> `setTimeout` at all,
>>
>> Right. CSS transitions, animations, keyframes. Or, for scripting,
>> requestAnimationFrame.
>>
>>> choosing `setInterval` instead,
>>
>> Oh my.
> 
> Please remember the context: a discussion about whether it was
> necessary to clean up behind a `setTimeout`.  I was bringing a class
> of animations into this as an example of code that often made heavy
> uses of `setTimeout` often without doing the cleanup that Thomas
> insisted was necessary.  I was not trying to list all the forms of
> animation available.
> 
> Thomas claims to have evidence that he's unwilling to share that code
> of this sort is necessary:
> 
>     var field = …
> 
>     var t = window.setTimeout(function () {
>       field.focus();
>       window.clearTimeout(t);
>       field = null;
>       t = null;

This does not clean up the window.setTimeout,
but only gives another [i.c. null] value 
to the variable pointer t.

If the window.setTimeout would still exist,
which I doubt, it just would not be reachable anymore.

And that would make possible garbage collection later?
No I doubt that, in any reasonable javascript implementation.

However if the window.setTimeout is anonymous, as below,
the availability to garbage collection would be the same.

And anyway, a "spent" window.setTimeout,
either fired or reset, should either not need garbage collection,
or should get that independent of any useless still existing pointer.


>     }, 50);
> 
> and that my alternative is harmful:
> 
>     (function() {
>         var field = …;
>         window.setTimeout(function () {
>             field.focus();
>         }, 50);
>     }());
> 
> I've never seen any evidence of that.  That's the context of these
> discussion.  Animations are not really central to the point, just one
> example.
> 
>   -- Scott
> 



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web