Augmenting Types
in [JavaScript]
|
From: Thomas 'PointedEars' Lahn on 5 Jan 2010 00:39 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> David Mark wrote: >> >> > Thomas 'PointedEars' Lahn wrote: >> >> >> David Mark wrote: >> >> >> > Obviously the error was _not_ caught by try-catch, >> >> >> I have not seen the source code leading to this error message yet, >> >> >> so I cannot tell whether try-catch would help there. I wonder how >> >> >> you could. >> >> > Huh? If there was a try-catch (as there always should have been in >> >> > jQuery), there would be no exception, no dialog, etc. >> >> Not necessarily. It depends on the implementation and the runtime >> >> environment which errors cause error messages despite try-catch. >> > Yes, and the one in question has always been catch-able. >> How can you possibly know without having seen the source code? > > Because we are not talking about _that_ source code. We are talking > about something else. The screen shot was just an example. If the example error message was not an example for the source code which caused the error, what else could it possibly be an example for? >> > 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? > The message on the dialog in the screen shot > was supposedly good news for "such exceptions." Yes. > 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. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: David Mark on 5 Jan 2010 00:50 On Jan 5, 12:39 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> 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: > >> >> >> > Obviously the error was _not_ caught by try-catch, > >> >> >> I have not seen the source code leading to this error message yet, > >> >> >> so I cannot tell whether try-catch would help there. I wonder how > >> >> >> you could. > >> >> > Huh? If there was a try-catch (as there always should have been in > >> >> > jQuery), there would be no exception, no dialog, etc. > >> >> Not necessarily. It depends on the implementation and the runtime > >> >> environment which errors cause error messages despite try-catch. > >> > Yes, and the one in question has always been catch-able. > >> How can you possibly know without having seen the source code? > > > Because we are not talking about _that_ source code. We are talking > > about something else. The screen shot was just an example. > > If the example error message was not an example for the source code > which caused the error, what else could it possibly be an example for? > > >> > 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? And because we were talking about instantiating an ActiveX object. If a try-catch was used, the exception would have been caught. Conversely, if no try- catch was used (as with jQuery), the exception will not be caught. Now are we clear on what is a completely moot point? > > > The message on the dialog in the screen shot > > was supposedly good news for "such exceptions." > > Yes. > > > 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). ;) 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). The original aside was to alleviate any confusion that _beginners_ may have with the wording in the screen shot. Why are you muddying the waters like this?
From: Thomas 'PointedEars' Lahn on 5 Jan 2010 01:42 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: >> >> >> >> > Obviously the error was _not_ caught by try-catch, >> >> >> >> I have not seen the source code leading to this error message >> >> >> >> yet, so I cannot tell whether try-catch would help there. I >> >> >> >> wonder how you could. >> >> >> > Huh? If there was a try-catch (as there always should have been >> >> >> > in jQuery), there would be no exception, no dialog, etc. >> >> >> Not necessarily. It depends on the implementation and the runtime >> >> >> environment which errors cause error messages despite try-catch. >> >> > Yes, and the one in question has always been catch-able. >> >> How can you possibly know without having seen the source code? >> > Because we are not talking about _that_ source code. We are talking >> > about something else. The screen shot was just an example. >> If the example error message was not an example for the source code >> which caused the error, what else could it possibly be an example for? You did not answer that question. >> >> > 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. > 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. > If a try-catch was used, the exception would have been caught. Iff the error was catchable, which we do not know. > Conversely, Non sequitur. > 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. > Now are we clear on what is a completely moot point? Not at all. >> > The message on the dialog in the screen shot >> > was supposedly good news for "such exceptions." >> >> Yes. >> >> > 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? > Other scripts can try to get by after that, Define: other scripts > but it is unlikely they will succeed How so? They could use completely different references. > (and I can't believe I'm writing all of this again). You better believe it. As for "again": Message-ID for some *facts*? > The original aside was to alleviate any confusion that _beginners_ may > have with the wording in the screen shot. Maybe so. > Why are you muddying the waters like this? On the contrary, I seek clarity on what has already been muddied by you. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Garrett Smith on 5 Jan 2010 02:07 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Garrett Smith wrote: >>>> Ryan Chan wrote: >>>>> Have read Douglas Crockfore's JavaScript The Good Parts, it recommend >>>>> Augmenting Types, e.g. >>>>> >>>>> Function.prototype.method = function(name, func) { >>>>> this.prototype[name] = func; >>>>> return this; >>>>> }; >>>>> >>>> This is not a good thing. >>>> The `method` method is not related to all Functions; only constructors. >>> Non sequitur. All Function instances may be used as constructor. >> No, none of the built in functions may be used as a constructor. > > That is obviously wrong. RTFM. > >>>> It takes more time to comprehend that method than:- >>>> >>>> MyConstructor.prototype.foo = fooFunc; >>> Only that this is not equivalent (note the `return'), and if >>> feature-tests were added as they should be, there would probably be the >>> clutter that you are talking of below, in the main code. >> Feature tests for what? > > Callability, to the extent this can be detected. The method `method' here > is supposed to add only *methods* after all. > >>>> That method is unnecessary, >>> No. >> No *what*? > > No, it is not unnecessary. > >>>> adds overhead, >>> Any abstraction does. That is not a good reason for not doing it. >> Yes, actually it is. There is no benefit to that method being there. > > There is apparently no benefit that you can see, but there is one. > With no evidence that there is benefit. >>>> adds clutter. >>> Define: clutter. >> Useless code that takes more time to comprehend (by machines or humans). > > But it is not useless, and if the method was named properly, the resulting > code would not be considerably harder to understand for humans. As to what > machines could understand, we should not argue about that as long as > machines have not achieved intelligence. > When I see:- Function.method( (looks to see method signature again).. When I see Base.method("foo", fooFunc), it is not as instantly recognizable as Base.prototype.foo = fooFunc; The latter, I can know exactly what it does, whereas with the former, I have to remember what Base.method does. Again with the packaging of software, if a constructor depends on a 20k file of Function.prototype.method plus other things, just so it can get that 20k file's Function.prototype.method, it becomes less attractive. Ifthat 20k file contains a myriad of other things such as typechecking, String.prototype.supplant, or other such junk, then the prospect of using that particular dependency becomes even less attractive. The same exact argument applies to namespacing, too. I don't want a namespace function when I have to take a bunch of other crapola along with it. If the thing that I am interested in has a large dependency, it is less appealing. That, to me, is why the js libraries are at huge disadvantage. To use something of Dojo or YUI or Ext requires a very large core dependency. A lot of that core is code that is both unnecessary and in many cases (especially for Ext and Dojo) buggy. Small tweaks for performance matter but the architecture and design of a framework can have more significant impacts on performance. >> Another example of useless code:- >> >> | if(goog.isDef( node.nextSibling )) { >> | >> | } >> >> Method goog.isDef is potentially misleading to someone who is less >> familiar with the Google closure library. > > Possible, but that does not preclude abstractions from being not misleading > in general. > >> The abstraction doesn't really add any value. > > Impossible to say without seeing the called code. In any case, your proof- > by-example is fallacious. > >>>> By creating your own namespace, collisions like that can be avoided. >>> Whereas `namespace' should be understood as syntactic sugar created by >>> aggregation, not (yet) as a language feature. One should therefore be >>> aware that the less probability of name collision that this >>> "namespacing" provides comes with a performance penalty. >> The greater performance penalty is not in the runtime overhead of >> calling `namespace`; it's with the management of the `namespace` code >> itself. > > No, it is within the aggregation that comes with this "namespacing" which > forces more evaluation. Local aliasing cannot prevent that, only alleviate > it. > >> The file where `namespace` is defined should be looked at before >> including it in the application. If that file contains a bunch of junk, >> then the prospect of using that file, and consequently the thing that >> uses it, becomes less appealing. > > You miss the point: `foo.bar.baz' is always less efficient than `baz'. > No, I don't miss your point. I got it. You wrote that foo.bar.baz is less efficient that just `foo`. You're right; it is. But that is hardly a consideration because the efficiency of lookup for user-defined objects is fast. (function(){ var foo = { bar : {baz :0 } }; var d = new Date; for(var i = 0; i < 10000; i++) foo.bar.baz = foo.bar.baz+1; return new Date-d; })(); Ten thousand iterations and it is running in under 10ms. Performance with DOM operations is a different matter. For DOM ops, [[Get]] is going to often perform not just a property lookup, but something else more expensive. (function(){ var foo = document.body; var d = new Date; for(var i = 0; i < 10000; i++) foo.firstChild.nextSibling return new Date-d; })(); Bumps it up to 200ms in IE. Then there is the issue of evaluating the call to the namespace function. That will happen at load time, not runtime. A heavy application might use up to 50 calls to create a namespace. That would not be measurable in milliseconds (maybe 1 millisecond on a 2ghz machine). If I bump the number of calls up to 1000, and declare 1000 unique "packages" off a "base" package, with two sub-packages, there should be a total of 3001 packages d.b0, d.b0.c, d.b0.c.d, d.b1... (function(){ var APE= window.APE; var d = new Date; for(var i = 0; i < 1000; i++) APE.namespace("d" + ".b" + i + ".c.d"); return new Date-d; })(); IE7 121 Firefox: 36 Opera 12 That's up to 121ms in IE7. That is measurable. It is a lot of packages, though. Now notice in the example that "d" is the "base" "package". If I instead use a unique base package, say, "d" + i, the performance decreases measurably. This is because a the base object has a longer chain. If I use a unique "base" "package" and shorten the chain, then performance is still decreased in IE7. This is because I am now creating 4000 unique packages, and I am accessing properties off the global object (999 more than before). Accessing properties off the global object is slower than accessing properties off a user defined object. Access property off global object: (function(){ var p = window; var d = new Date; for(var i = 0; i < 10000; i++) p["d" + ".b" + i + ".c.d"] = i; return new Date-d; }()) IE7: 129 FF: 33 Opera: 28 Access property off user-defined object: (function(){ var p = {}; var d = new Date; for(var i = 0; i < 10000; i++) p["d" + ".b" + i + ".c.d"] = i; return new Date-d; }()) IE7: 97 FF3.5: 25 Opera: 27 The namespace function creating 3000 namespaces in IE is measurable. Creating maybe 100 namespaces seems like a big stretch of practicality in an application. Probably 10 namespaces is more like a reality. The overhead for that would be nanoseconds. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 5 Jan 2010 02:44
Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> Garrett Smith wrote: >>>>> That method is unnecessary, >>>> No. >>> No *what*? >> No, it is not unnecessary. >> >>>>> adds overhead, >>>> Any abstraction does. That is not a good reason for not doing it. >>> Yes, actually it is. There is no benefit to that method being there. >> There is apparently no benefit that you can see, but there is one. > > With no evidence that there is benefit. Please trim your quotes. The obvious benefit of the method currently named `method' is that it returns a reference to the augmented object; that reference can be reused. The less obvious benefit is that it can be extended so that it includes e.g. feature tests which would otherwise "clutter up" the main code every time. >>>>> adds clutter. >>>> Define: clutter. >>> Useless code that takes more time to comprehend (by machines or >>> humans). >> >> But it is not useless, and if the method was named properly, the >> resulting code would not be considerably harder to understand for >> humans. As to what machines could understand, we should not argue >> about that as long as machines have not achieved intelligence. > > When I see:- > > Function.method( > > (looks to see method signature again).. > > When I see Base.method("foo", fooFunc), it is not as instantly > recognizable as Base.prototype.foo = fooFunc; The latter, I can know > exactly what it does, whereas with the former, I have to remember what > Base.method does. I said "if the method was named properly". > Again with the packaging of software, if a constructor depends on a 20k > file of Function.prototype.method plus other things, just so it can get > that 20k file's Function.prototype.method, it becomes less attractive. Non sequitur. You are falsely assuming this must be the case. > If that 20k file contains a myriad of other things such as typechecking, > String.prototype.supplant, or other such junk, then the prospect of > using that particular dependency becomes even less attractive. Another fallacy. > The same exact argument applies to namespacing, too. I don't want a > namespace function when I have to take a bunch of other crapola along > with it. If the thing that I am interested in has a large dependency, it > is less appealing. ACK > That, to me, is why the js libraries are at huge disadvantage. To use > something of Dojo or YUI or Ext requires a very large core dependency. A > lot of that core is code that is both unnecessary and in many cases > (especially for Ext and Dojo) buggy. That is, this subset of libraries, not libraries in general. > Small tweaks for performance matter but the architecture and design of a > framework can have more significant impacts on performance. ACK >>>>> By creating your own namespace, collisions like that can be avoided. >>>> Whereas `namespace' should be understood as syntactic sugar created by >>>> aggregation, not (yet) as a language feature. One should therefore be >>>> aware that the less probability of name collision that this >>>> "namespacing" provides comes with a performance penalty. >>> The greater performance penalty is not in the runtime overhead of >>> calling `namespace`; it's with the management of the `namespace` code >>> itself. >> >> No, it is within the aggregation that comes with this "namespacing" >> which forces more evaluation. Local aliasing cannot prevent that, only >> alleviate it. >> >>> The file where `namespace` is defined should be looked at before >>> including it in the application. If that file contains a bunch of junk, >>> then the prospect of using that file, and consequently the thing that >>> uses it, becomes less appealing. >> >> You miss the point: `foo.bar.baz' is always less efficient than `baz'. > > No, I don't miss your point. I got it. Your statement indicated otherwise. Then again, I have no idea what "calling `namespace'" exactly means in your book. > You wrote that foo.bar.baz is less efficient that just `foo`. You're > right; it is. But that is hardly a consideration because the efficiency > of lookup for user-defined objects is fast. Non sequitur. "fast" is relative. > (function(){ > var foo = { bar : {baz :0 } }; > var d = new Date; > for(var i = 0; i < 10000; i++) > foo.bar.baz = foo.bar.baz+1; > return new Date-d; > })(); > > Ten thousand iterations and it is running in under 10ms. Your test case is flawed as the function code does not contain any identifier referring outside of the function. > Performance with DOM operations is a different matter. For DOM ops, > [[Get]] is going to often perform not just a property lookup, but > something else more expensive. > > (function(){ > var foo = document.body; > var d = new Date; > for(var i = 0; i < 10000; i++) > foo.firstChild.nextSibling > return new Date-d; > })(); > > Bumps it up to 200ms in IE. Which is also due to the fact that this time there is an identifier referring outside of the function, document. My point exactly. > Then there is the issue of evaluating the call to the namespace > function. But nobody talked of a "namespace function" yet. (Perhaps that is what you mean by "calling `namespace'"?) > That will happen at load time, not runtime. A heavy > application might use up to 50 calls to create a namespace. That would > not be measurable in milliseconds (maybe 1 millisecond on a 2ghz > machine). > > If I bump the number of calls up to 1000, and declare 1000 unique > "packages" off a "base" package, with two sub-packages, there should be > a total of 3001 packages d.b0, d.b0.c, d.b0.c.d, d.b1... > > (function(){ > var APE= window.APE; I do hope you are not augmenting host objects. > var d = new Date; > for(var i = 0; i < 1000; i++) > APE.namespace("d" + ".b" + i + ".c.d"); What exactly does it do? (No, I am not going to dig through your code.) > return new Date-d; > })(); > > [...] All this is very interesting, but it evades the issue. > Access property off global object: You have been told before that `window' is _not_ an appropriate means to refer to the global object. > (function(){ > var p = window; > var d = new Date; > for(var i = 0; i < 10000; i++) > p["d" + ".b" + i + ".c.d"] = i; So you are augmenting host objects after all? PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann |