Augmenting Types
in [JavaScript]
|
From: Jorge on 3 Jan 2010 20:59 On Jan 4, 2:16 am, David Mark <dmark.cins...(a)gmail.com> wrote: > On Jan 3, 8:11 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > > > > > > > On Jan 4, 1:45 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > On Jan 3, 7:26 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > > > > > On Jan 4, 12:21 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > > > You truly are a student of Crockford. > > > > > Yes I am. > > > > > > For about the millionth time, > > > > > that method doesn't work in "ancient" browsers like Safari 2. > > > > > And who cares ? If Safari 2 is broken it's not your/my problem (as > > > > developers). > > > > Here we go again. Lacking the hasOwnProperty method does not indicate > > > that the browser is broken.(...) > > > Safari 2.0.4 does have .hasOwnProperty()... > > That's as maybe. Now check 2.0.3, then 2.02... So you admit that you really don't know what you were talking about ? -- Jorge.
From: David Mark on 3 Jan 2010 21:17 On Jan 3, 8:59 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > On Jan 4, 2:16 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > > On Jan 3, 8:11 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > > > > On Jan 4, 1:45 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > > On Jan 3, 7:26 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > > > > > > On Jan 4, 12:21 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > > > > You truly are a student of Crockford. > > > > > > Yes I am. > > > > > > > For about the millionth time, > > > > > > that method doesn't work in "ancient" browsers like Safari 2. > > > > > > And who cares ? If Safari 2 is broken it's not your/my problem (as > > > > > developers). > > > > > Here we go again. Lacking the hasOwnProperty method does not indicate > > > > that the browser is broken.(...) > > > > Safari 2.0.4 does have .hasOwnProperty()... > > > That's as maybe. Now check 2.0.3, then 2.02... > > So you admit that you really don't know what you were talking about ? Not sure how you figure that, but then you are obviously mad. :)
From: Garrett Smith on 3 Jan 2010 22:28 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. >> 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? >> That method is unnecessary, > > No. > No *what*? >> not well named, > > True, it would only qualify as `method' if it checked for method references > for the second argument, and the property name misses a verb (e.g. > setMethod). > Right. >> 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. >> adds clutter. > > Define: clutter. > Useless code that takes more time to comprehend (by machines or humans). 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. The abstraction doesn't really add any value. >> 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. 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 4 Jan 2010 00:02 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. >>> 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. > 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'. PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: kangax on 4 Jan 2010 00:43
On 1/3/10 8:43 PM, David Mark wrote: > On Jan 3, 8:34 pm, David Mark<dmark.cins...(a)gmail.com> wrote: >> On Jan 3, 8:17 pm, Jorge<jo...(a)jorgechamorro.com> wrote: >> >>> On Jan 4, 1:45 am, David Mark<dmark.cins...(a)gmail.com> wrote: >> >>>> LOL. So you should just screw all IE users and figure they will be >>>> grateful for the tough love? Are you insane? >> >>> Don't know where you've been lately, but the days when you had to use >>> IE, yes or yes, are gone. >> >> Huh? I don't know where _you_ have been lately, but many large >> corporations have endless seas of cubes stocked with IE users. Some >> even have ActiveX and/or JS disabled _for them_ when using the public >> Internet. Try that combo (both off) and notice that 90% of the Web >> falls apart (100% of jQuery-enhanced sites). > > Correction. I meant to say that 100% of jQuery-enhanced sites will > fail with ActiveX off (at least if they try to use Ajax). With both > off, perhaps 50% (just a guess). That is the only sort of > "progressive" enhancement that jQuery and the like allow for (on or > off). They won't _just fail_. 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. User can choose to disable scripts and proceed with a fully functional page/app (that is, if things work without scripting, of course :)). I don't know if this popup appears in IE consistently. There's probably also a chance of popup being disabled (e.g. by administrator); or user not understanding what popup message means and choosing to leave script running, ending up with defunct application. But obviously there's really no reason to let errors like this happen. I think the problem is that not many developers are aware of a possibility for ActiveX to be disabled, and what to do about all this. -- kangax |