Augmenting Types
in [JavaScript]
|
From: Thomas 'PointedEars' Lahn on 5 Jan 2010 03:08 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> David Mark wrote: >> >> > Thomas 'PointedEars' Lahn wrote: >> >> >> David Mark wrote: >> >> >> > Thomas 'PointedEars' Lahn wrote: >> >> >> >> David Mark wrote: >> >> >> >> > It would be pretty ludicrous if it weren't (almost as >> >> >> >> > ludicrous as not using a try-catch when instantiating an >> >> >> >> > ActiveX object). ;) >> >> >> >> So you say this exception is catchable, yet you said in >> <news:05599f98-4a69-49c7-9fbd-8014c0020abc(a)a6g2000yqm.googlegroups.com> >> >> >> >> that "there is no recovery from such an exception." >> >> >> >> Something does not add up here. >> >> >> > An _uncaught_ exception. >> >> >> Again, how can you possibly know? >> >> > Because the browser threw up an error message? >> >> No, AISB that is a misconception. >> > Not in the case of ActiveX instantiation (which is what we were >> > talking about). >> >> But the screenshot, which you were referring to with "such an error", >> has nothing with ActiveX instantiation, by your own account. > > And how many times do I have to repeat that the screen shot was just > for illustration (as Kangax mentioned too?) Nobody cares what code > was used to create the illustration. :) One should if an argument like yours is based on it. >> >> > And because we were talking about instantiating an ActiveX object. >> >> How can you possibly know that this applies for the screenshot >> >> without having seen the source code that lead to it? You keep >> >> evading that simple question. >> > For the last time, as Kangax noted, that screen shot was not generated >> > by instantiating an ActiveX object. It was simply an illustration. >> So if the screenshot was not of an error message generated by >> instantiating an ActiveX object, how can you possibly know that there is >> "no recovery from such an error", given that you have not even seen the >> source code that lead to it (you only know that ActiveX objects are not >> involved)? > > You just can't seem to get your brain around this. I wasn't referring > to whatever error was used for the illustration, but the error that we > were discussing in the first place, which throws up the _same_ dialog > with a different message. The screenshot is based on a completely different use-case then, which you know nothing about. Yet you insist that you could tell 1. whether the exception was catchable; 2. whether try-catch was used or not; 3. how script code would be executed if one selected the "Yes" button. That is illogical. >> >> > If a try-catch was used, the exception would have been caught. >> >> Iff the error was catchable, which we do not know. >> > We do know that. >> No, we do not. We have not seen the source code, so all this is mere >> assumption of yours. > > Again, nobody cares about the whatever code was used to generate that > illustration. No, *you* do not care about it, for sure. > It's irrelevant and how can you keep harping on it after all of this > discussion? Because you referred to it ("such an error"). >> > As I said, it would be _ludicrous_ if MS did not allow you to catch >> > such exceptions >> And I do not concur. > > It wouldn't be ludicrous? How, pray tell, would you instantiate > ActiveX objects if there was no way to account for the fact that they > may not instantiate? Wrong question. Whether it would be ludicrous or not depends on the context, i.e. on the use-case and on the person making that assessment. >> > (given the fact that the component may not be available). >> Non sequitur.* > > I really dislike this sort of endless arguing about nothing. Then I suggest you do not make fallacious arguments, and be clearer (less pictorial, perhaps) in our wording. I am only trying my best here to get some clarity into this "muddied water" of yours, and you are not making it easy. >> >> > if no try-catch was used (as with jQuery), the exception will not >> >> > be caught. That goes without saying. What does not go without >> >> > saying is that an error message can be displayed even though the >> >> > exception was attempted to be caught with try-catch, a fact that >> >> > you still appear to miss. >> > I miss no such thing. In the context we are discussing (ActiveX >> > object instantiation), it does not apply. >> Why the inappropriate example then? > > What inappropriate example? The screen shot? As Kangax noted, it was > for illustration purposes only and the error message would be > different if it were actually generated by a failed ActiveX > instantiation. Sheesh. The error message would have been different, the underlying source code would have been different, and the outcome of selecting "Yes" might also have been different. Exactly my point. >> >> >> > I was pointing out that it was not (i.e. it would not >> >> >> > magically recover on clicking "No"). Clear now? >> >> >> No, for there is a "Yes" button which facilitates the recovery. >> >> > The "Yes" button doesn't recover anything. The execution has >> >> > _dropped dead_ at that point (i.e. if you can see the exception >> >> > dialog, it's too late). ;) >> >> Too late for what exactly? Is this all mere assumption? >> > Too late for the script in question to go on about its merry way. >> Is there any proof for your assumption? > > Proof that uncaught exceptions derail executions without recourse? Yes (IIUC). >> >> > Other scripts can try to get by after that, >> >> Define: other scripts >> > "Other scripts on the page" as mentioned on the dialog in question. >> > This really is a ludicrous discussion at this point. >> That is a recursive definition, so I have to concur with your >> assessment. > > I have no idea what you are talking about at this point. You define "other scripts" as "other scripts on the page" which is not particularly helpful for knowing what "other scripts" is supposed to be. >> >> > but it is unlikely they will succeed >> >> How so? They could use completely different references. >> > Once one script blows up, all bets are off. The document may not even >> > be usable at that point (let alone script-able in any sort of >> > predictable manner). But sure, some scripts could succeed. Seems >> > like I already said that. >> Your probability argument is fallacious. > > I don't think so. You do not know anything of the other code, so you are not in a position to assess the probability of failure. >> >> > (and I can't believe I'm writing all of this again). >> >> You better believe it. As for "again": Message-ID for some *facts*? >> > Parse error (and I can't believe I said _that_). >> >> You have stated that this was not the first time you said it. So there >> must be a Message-ID of a posting in which you said it before, >> containing facts to support your assumption. Well? >> >> > Why are you muddying the waters like this? >> >> On the contrary, I seek clarity on what has already been muddied by >> >> you. >> > Well, it isn't working. >> Unfortunately. > > Can we agree to stop trying to clarify whatever it is you think needs > clarifying then? I am afraid we cannot. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Jorge on 5 Jan 2010 03:23 On Jan 5, 8:07 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > (...) > Accessing properties off the global object is slower than accessing > properties off a user defined object. > > Access property off global object: > (...) > Access property off user-defined object: > (...) OMG. What are you saying ? -- Jorge.
From: David Mark on 5 Jan 2010 03:28 Thomas 'PointedEars' Lahn wrote: [...] > > One should if an argument like yours is based on it. My argument is not based on it at all. Why you can't see that is beyond me. It's like you've got some wires crossed and I can't find the short-circuit. I'm tired of trying. > >>>>>> And because we were talking about instantiating an ActiveX object. >>>>> How can you possibly know that this applies for the screenshot >>>>> without having seen the source code that lead to it? You keep >>>>> evading that simple question. >>>> For the last time, as Kangax noted, that screen shot was not generated >>>> by instantiating an ActiveX object. It was simply an illustration. >>> So if the screenshot was not of an error message generated by >>> instantiating an ActiveX object, how can you possibly know that there is >>> "no recovery from such an error", given that you have not even seen the >>> source code that lead to it (you only know that ActiveX objects are not >>> involved)? >> You just can't seem to get your brain around this. I wasn't referring >> to whatever error was used for the illustration, but the error that we >> were discussing in the first place, which throws up the _same_ dialog >> with a different message. > > The screenshot is based on a completely different use-case then, which you > know nothing about. Yet you insist that you could tell > > 1. whether the exception was catchable; > 2. whether try-catch was used or not; > 3. how script code would be executed if one selected the "Yes" button. > > That is illogical. *Sigh* Except that I never asserted anything about the code used to generate that screen shot. > >>>>>> If a try-catch was used, the exception would have been caught. >>>>> Iff the error was catchable, which we do not know. >>>> We do know that. >>> No, we do not. We have not seen the source code, so all this is mere >>> assumption of yours. >> Again, nobody cares about the whatever code was used to generate that >> illustration. > > No, *you* do not care about it, for sure. Why would I? Kangax could shed light on it, but who cares? > >> It's irrelevant and how can you keep harping on it after all of this >> discussion? > > Because you referred to it ("such an error"). You just won't let that go, will you? I cleared that up 100 messages back. :) Arguing endlessly about vague and misinterpreted semantics is a complete waste of time. > >>>> As I said, it would be _ludicrous_ if MS did not allow you to catch >>>> such exceptions >>> And I do not concur. >> It wouldn't be ludicrous? How, pray tell, would you instantiate >> ActiveX objects if there was no way to account for the fact that they >> may not instantiate? > > Wrong question. Whether it would be ludicrous or not depends on the > context, i.e. on the use-case and on the person making that assessment. The use case in question has never been in doubt (except perhaps to you). > >>>> (given the fact that the component may not be available). >>> Non sequitur.* >> I really dislike this sort of endless arguing about nothing. > > Then I suggest you do not make fallacious arguments, and be clearer (less > pictorial, perhaps) in our wording. I am only trying my best here to get > some clarity into this "muddied water" of yours, and you are not making it > easy. Nobody's paying attention at this point. I promise. :) > >>>>>> if no try-catch was used (as with jQuery), the exception will not >>>>>> be caught. That goes without saying. What does not go without >>>>>> saying is that an error message can be displayed even though the >>>>>> exception was attempted to be caught with try-catch, a fact that >>>>>> you still appear to miss. >>>> I miss no such thing. In the context we are discussing (ActiveX >>>> object instantiation), it does not apply. >>> Why the inappropriate example then? >> What inappropriate example? The screen shot? As Kangax noted, it was >> for illustration purposes only and the error message would be >> different if it were actually generated by a failed ActiveX >> instantiation. Sheesh. > > The error message would have been different, the underlying source code > would have been different, and the outcome of selecting "Yes" might also > have been different. Exactly my point. I'm using a newsreader now. I can plonk you for real. Fair warning. :) > >>>>>>>> I was pointing out that it was not (i.e. it would not >>>>>>>> magically recover on clicking "No"). Clear now? >>>>>>> No, for there is a "Yes" button which facilitates the recovery. >>>>>> The "Yes" button doesn't recover anything. The execution has >>>>>> _dropped dead_ at that point (i.e. if you can see the exception >>>>>> dialog, it's too late). ;) >>>>> Too late for what exactly? Is this all mere assumption? >>>> Too late for the script in question to go on about its merry way. >>> Is there any proof for your assumption? >> Proof that uncaught exceptions derail executions without recourse? > > Yes (IIUC). That's like asking to prove that 1 + 1 = 2. What's the point? > >>>>>> Other scripts can try to get by after that, >>>>> Define: other scripts >>>> "Other scripts on the page" as mentioned on the dialog in question. >>>> This really is a ludicrous discussion at this point. >>> That is a recursive definition, so I have to concur with your >>> assessment. >> I have no idea what you are talking about at this point. > > You define "other scripts" as "other scripts on the page" which is not > particularly helpful for knowing what "other scripts" is supposed to be. This is going nowhere. > >>>>>> but it is unlikely they will succeed >>>>> How so? They could use completely different references. >>>> Once one script blows up, all bets are off. The document may not even >>>> be usable at that point (let alone script-able in any sort of >>>> predictable manner). But sure, some scripts could succeed. Seems >>>> like I already said that. >>> Your probability argument is fallacious. >> I don't think so. > > You do not know anything of the other code, so you are not in a position to > assess the probability of failure. Whatever. > >>>>>> (and I can't believe I'm writing all of this again). >>>>> You better believe it. As for "again": Message-ID for some *facts*? >>>> Parse error (and I can't believe I said _that_). >>> You have stated that this was not the first time you said it. So there >>> must be a Message-ID of a posting in which you said it before, >>> containing facts to support your assumption. > > Well? Well what? You snipped whatever it was I was talking about. > >>>>>> Why are you muddying the waters like this? >>>>> On the contrary, I seek clarity on what has already been muddied by >>>>> you. >>>> Well, it isn't working. >>> Unfortunately. >> Can we agree to stop trying to clarify whatever it is you think needs >> clarifying then? > > I am afraid we cannot. > Dammit. :( But seriously, this will be my last word on this "topic". I just wanted to test the TB setup. Thanks!
From: Thomas 'PointedEars' Lahn on 5 Jan 2010 04:11 David Mark wrote: [Quotation restored] > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >>> And how many times do I have to repeat that the screen shot was just >>> for illustration (as Kangax mentioned too?) Nobody cares what code >>> was used to create the illustration. :) >> One should if an argument like yours is based on it. > > My argument is not based on it at all. OK, let's assume that for brevity. Hopefully that finally leads somewhere. >>> You just can't seem to get your brain around this. I wasn't referring >>> to whatever error was used for the illustration, but the error that we >>> were discussing in the first place, which throws up the _same_ dialog >>> with a different message. >> >> The screenshot is based on a completely different use-case then, which >> you know nothing about. Yet you insist that you could tell >> >> 1. whether the exception was catchable; >> 2. whether try-catch was used or not; >> 3. how script code would be executed if one selected the "Yes" button. >> >> That is illogical. > > *Sigh* Except that I never asserted anything about the code used to > generate that screen shot. Then I am at a loss as to what your "such an exception" was supposed to refer to in the following dialog (verbatim quote, only that your first followup to kangax's posting was snipped). David Mark wrote in <news:05599f98-4a69-49c7-9fbd-8014c0020abc(a)a6g2000yqm.googlegroups.com>: | kangax wrote: | > David Mark wrote: | >> kangax wrote: | >>> Last time I checked IE would actually propose to disable scripts as | >>> soon as "automation server can't create object ..." error (the one | >>> that's thrown when initializing ActiveXObject with disabled ActiveX | >>> controls) happened. | >> | >> Propose? I've never seen it do anything but throw that obscure error | >> message at the user. What version/configuration are you talking | >> about? | > | > Something like this � | > <http://chadsanswers.com/wp-content/uploads/2009/04/toaster.jpg>, but | > different error of course. | | [...] | And I think it bears pointing out that there is no recovery from such ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | an exception. It is highly unlikely that subsequent executions on the ^^^^^^^^^^^^^ | page will be successful after such a flame-out. (Because if it referred to ActiveX instantiation instead, one *can* "recover" from that and your statement, that one could not, would have been wrong.) And, as I see it, kangax was wrong anyway because if "IE proposes" anything it is that script execution continues despite of the error as _"Yes"_ ("continue running scripts on this page") is the default. >>>>>>> If a try-catch was used, the exception would have been caught. >>>>>> Iff the error was catchable, which we do not know. >>>>> We do know that. >>>> No, we do not. We have not seen the source code, so all this is mere >>>> assumption of yours. >>> Again, nobody cares about the whatever code was used to generate that >>> illustration. >> No, *you* do not care about it, for sure. > > Why would I? Kangax could shed light on it, but who cares? I wish he would because I do care. >>>>>>> if no try-catch was used (as with jQuery), the exception will not >>>>>>> be caught. That goes without saying. What does not go without >>>>>>> saying is that an error message can be displayed even though the >>>>>>> exception was attempted to be caught with try-catch, a fact that >>>>>>> you still appear to miss. >>>>> I miss no such thing. In the context we are discussing (ActiveX >>>>> object instantiation), it does not apply. >>>> Why the inappropriate example then? >>> What inappropriate example? The screen shot? As Kangax noted, it was >>> for illustration purposes only and the error message would be >>> different if it were actually generated by a failed ActiveX >>> instantiation. Sheesh. >> >> The error message would have been different, the underlying source code >> would have been different, and the outcome of selecting "Yes" might also >> have been different. Exactly my point. > > I'm using a newsreader now. That's good to hear. > I can plonk you for real. Fair warning. :) :) >>>>>>>>> I was pointing out that it was not (i.e. it would not >>>>>>>>> magically recover on clicking "No"). Clear now? >>>>>>>> No, for there is a "Yes" button which facilitates the recovery. >>>>>>> The "Yes" button doesn't recover anything. The execution has >>>>>>> _dropped dead_ at that point (i.e. if you can see the exception >>>>>>> dialog, it's too late). ;) >>>>>> Too late for what exactly? Is this all mere assumption? >>>>> Too late for the script in question to go on about its merry way. >>>> Is there any proof for your assumption? >>> Proof that uncaught exceptions derail executions without recourse? >> >> Yes (IIUC). > > That's like asking to prove that 1 + 1 = 2. Ahh, no, it is not. Perhaps I have been too imprecise: > What's the point? I would like to see proof that, as I understand you were saying, under any reasonable circumstances it is not possible for execution to recover from an uncatched or uncatchable exception *in MSHTML*, before I believe it. Because the asserted purpose of the "Yes" button in the error dialog casts doubt upon that. (It stands to reason that all script execution would stop with "No", no argument about that.) >>>>>>> Other scripts can try to get by after that, >>>>>> Define: other scripts >>>>> "Other scripts on the page" as mentioned on the dialog in question. >>>>> This really is a ludicrous discussion at this point. >>>> That is a recursive definition, so I have to concur with your >>>> assessment. >>> I have no idea what you are talking about at this point. >> You define "other scripts" as "other scripts on the page" which is not >> particularly helpful for knowing what "other scripts" is supposed to be. > > This is going nowhere. Unfortunately. Why would you not at least point me to the "other scripts"? :-( [Quotation restored] >>>>>>> The "Yes" button doesn't recover anything. The execution has >>>>>>> _dropped dead_ at that point (i.e. if you can see the exception >>>>>>> dialog, it's too late). ;) Other scripts can try to get by >>>>>>> after that, but it is unlikely they will succeed (and I can't >>>>>>> believe I'm writing all of this again). >>>>>> You better believe it. As for "again": Message-ID for some *facts*? >>>>> Parse error (and I can't believe I said _that_). >>>> You have stated that this was not the first time you said it. So >>>> there must be a Message-ID of a posting in which you said it before, >>>> containing facts to support your assumption. >> Well? > > Well what? You snipped whatever it was I was talking about. No, I am afraid you did that. Anyhow, where exactly are these facts that you provided and that I have snipped? So far I can see only more assumptions (like "execution has dropped dead at that point"). PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Jorge on 5 Jan 2010 10:47
On Jan 5, 9:23 am, Jorge <jo...(a)jorgechamorro.com> wrote: > On Jan 5, 8:07 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > > (...) > > Accessing properties off the global object is slower than accessing > > properties off a user defined object. > > > Access property off global object: > > (...) > > Access property off user-defined object: > > (...) > > OMG. What are you saying ? I mean, the code snippets that you've posted are comparing access time to an identifier at the end of the scope chain (a global) versus an identifier in the first link (a local var). That has nothing to do with whether the object is or isn't "user defined". -- Jorge. |