Augmenting Types
Ryan Chan
Augmenting Types, e.g.
Function.prototype.method = function(name, func) {
this.prototype[name] = func;
return this;
};
String.method('trim', function() {
return this.replace(/^\s+|\s+$/g, '');
});
Is this a good thing in your opinion?
David Mark
> Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
> Augmenting Types, e.g.
...among other bad things.
>
> Function.prototype.method = function(name, func) {
> this.prototype[name] = func;
> return this;
>
> };
>
> String.method('trim', function() {
> return this.replace(/^\s+|\s+$/g, '');
>
> });
Dear God. That's another step towards the abyss. :) First I find
out that YUI is crap and now this? Oh well, JSLint is nice anyway
(most of it).
>
> Is this a good thing in your opinion?
No.
Thomas 'PointedEars' Lahn
No, because the call to String.method() would unconditionally overwrite the
property value in case there was already such a method. There needs to be
one in conforming implementations of ECMAScript Edition 5, so if you use
this exact pattern, you would in effect be replacing the faster built-in
method by a slower user-defined one. It is understandable that the book
does not consider this possibility as Edition 5 was published not before
2009-12. However, that does not excuse the lack of feature test before the
assignment or the lack of a property registry to work around unwanted
enumeration.
As to the question you wanted to ask: Such syntactic sugar can be a good
thing if done properly, and there is little wrong with it in this example.
However, if you augment built-in prototype objects you need to be aware
that all objects that have them in their prototype chain inherit those
properties, and that at least new prototype properties are enumerable (see
for-in iteration). Especially, if you augment the Object prototype object
the new properties will show up with for-in iteration over Array instances,
as their prototype chain is
[object Array] --> Array.prototype --> Object.prototype
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Garrett Smith
> 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.
It takes more time to comprehend that method than:-
MyConstructor.prototype.foo = fooFunc;
That method is unnecessary, not well named, adds overhead, adds clutter.
I criticized this part in another thread:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/3a08fb741525ab6d/cd561210abc96faa#cd561210abc96faa
> String.method('trim', function() {
> return this.replace(/^\s+|\s+$/g, '');
> });
>
No, it is not a good idea to replace a built-in method with a
hand-rolled version; not without good reason. In fact, without good
reason, that has some negative consequences.
String.prototype.trim is an ES5 standard method. It is implemented in
Tracemonkey (in Firefox).
A good reason for doing that would be, say, if an implementation did not
yet support the new method, or if it was shown to be buggy, but only
then after performing a /feature test/. The FAQ contains an example of
just that.
When Douglas wrote that, he probably did not consider the possibility
that String.prototype.trim would be added to the language.
The consequence of adding String.prototype.trim is that it replaces the
built-in String.prototype.trim with a user-defined version. That
user-defined version will not perform as fast as native code that it
replaced and will throw errors when used in a generic context.
| The following steps are taken:
| 1. Call CheckObjectCoercible passing the this value as its argument.
| 2. Let S be the result of calling ToString, giving it the this value
| as its argument.
| 3. Let T be a String value that is a copy of S with both leading and
| trailing white space removed. The definition of white space is the
| union of WhiteSpace and LineTerminator.
| 4. Return T.
|
| NOTE The trim function is intentionally generic; it does not require
| that its this value be a String object. Therefore, it can be
| transferred to other kinds of objects for use as a method.
The following are specified to work in ES5:
var trimFn = String.prototype.trim;
trimFn.call( window.getSelection() )
trimFn.call( new Error("You broke it.") );
trimFn.call( window.location );
trimFn.call( document.links[0] );
var range = document.createRange();
range.selectNode(document.body);
trimFn.call(range);
In Firefox, they correctly do convert the thisArt to string, as
specified by the standard.
However, when Douglas' method replaces that, it results in a TypeError.
By creating your own namespace, collisions like that can be avoided.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
Thomas 'PointedEars' Lahn
> 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.
> 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.
> That method is unnecessary,
No.
> 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).
> adds overhead,
Any abstraction does. That is not a good reason for not doing it.
> adds clutter.
Define: clutter.
> 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.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
Jorge
The -handy- ability to -miraculously- extend types on the fly -at
runtime- is another of these awesome JS's features that Brendan Eich
put there just for you not to use it. LOL.
--
Jorge.
David Mark
Get a brain, Jorge. That's not what was asked.
Dmitry A. Soshnikov
For do not repeat myself: <URL:
http://groups.google.ru/group/comp.lang.javascript/browse_thread/thread/b5d5cf808c064462/bbfb83eb82ef9b41?hl=en#bbfb83eb82ef9b41>
You should understand first the main issues related to the augmenting
of the built-ins. After that you can decide yourself is it a good
thing or not.
In general, if you understand what you're doing, it's not a bad
practice at all.
/ds
Jorge
Dear God. NO. That's another step towards the abyss. :-)
--
Jorge.
David Mark
wrote:
> On 3 янв, 08:40, Ryan Chan <ryanchan...@gmail.com> 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;
>
> > };
>
> > String.method('trim', function() {
> > return this.replace(/^\s+|\s+$/g, '');
>
> > });
>
> > Is this a good thing in your opinion?
>
>
> You should understand first the main issues related to the augmenting
> of the built-ins. After that you can decide yourself is it a good
> thing or not.
>
> In general, if you understand what you're doing, it's not a bad
> practice at all.
>
In a Web page, it's generally a terrible idea as scripts typically
have to co-exist with others. It pays to be defensive. ;) And that
"method" method is ridiculous.
David Mark
Is that the "Jorge" re-mix? :(
Dmitry A. Soshnikov
> On Jan 3, 10:50 am, "Dmitry A. Soshnikov" <dmitry.soshni...@gmail.com>
> wrote:
>
>
>
> > On 3 янв, 08:40, Ryan Chan <ryanchan...@gmail.com> 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;
>
> > > };
>
> > > String.method('trim', function() {
> > > return this.replace(/^\s+|\s+$/g, '');
>
> > > });
>
> > > Is this a good thing in your opinion?
>
> > For do not repeat myself: <URL:http://groups.google.ru/group/comp.lang.javascript/browse_thread/thre...>
>
> > You should understand first the main issues related to the augmenting
> > of the built-ins. After that you can decide yourself is it a good
> > thing or not.
>
> > In general, if you understand what you're doing, it's not a bad
> > practice at all.
>
> terrible idea
> terrible
> terrible idea
Please, don't use demagogy, propaganda, and statement forms (novices
also read this and they can believe that propaganda is conclusive
true, but it's not always so) ;) Exchanging with meanings can't
operate with that. Or if you would like, please add "imHo" every time
you want to write so. It will be fairly, are you agree? ;)
> In a Web page, it's generally a terrible idea as scripts typically
> have to co-exist with others.
Well, yeah, I've mentioned - user should understand all the issues. If
he see the issues, he can decide do not do that. If not - he can do
that. It seems quite simple. Of cause, user should understand what
he's doing and why he's doing so.
For do not repeat myself, one more link: <URL:
http://groups.google.ru/group/comp.lang.javascript/browse_thread/thread/24ceb2af21b27a3b/560a9fb04339fdb8#f4ea783833329f83>
/ds
David Mark
wrote:
> On 3 янв, 19:06, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Jan 3, 10:50 am, "Dmitry A. Soshnikov" <dmitry.soshni...@gmail.com>
> > wrote:
>
> > > On 3 янв, 08:40, Ryan Chan <ryanchan...@gmail.com> 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;
>
> > > > };
>
> > > > String.method('trim', function() {
> > > > return this.replace(/^\s+|\s+$/g, '');
>
> > > > });
>
> > > > Is this a good thing in your opinion?
>
> > > For do not repeat myself: <URL:http://groups.google.ru/group/comp.lang.javascript/browse_thread/thre...>
>
> > > You should understand first the main issues related to the augmenting
> > > of the built-ins. After that you can decide yourself is it a good
> > > thing or not.
>
> > > In general, if you understand what you're doing, it's not a bad
> > > practice at all.
>
> > terrible idea
> > terrible
> > terrible idea
I didn't write this. (?!)
>
> Please, don't use demagogy, propaganda, and statement forms (novices
> also read this and they can believe that propaganda is conclusive
> true, but it's not always so) ;)
Please don't forge quotes. :(
Dmitry A. Soshnikov
>
> > > terrible idea
> > > terrible
> > > terrible idea
>
> I didn't write this. (?!)
>
>
>
> > Please, don't use demagogy, propaganda, and statement forms (novices
> > also read this and they can believe that propaganda is conclusive
> > true, but it's not always so) ;)
>
> Please don't forge quotes. :(
That was specially to show that I see your speaking manner and free
you from trying to do that (you can stop trying it, I've already
"appreciate" it) ;) You know, it also can be so, when person don't
completely understand what he's talking about, he can use some
demagogy and statement form for to show to the other readers, that
he's speaking with the sure tone. Sure better to use some strong words
such as "terrible" and so on. It can be treated by those who don't
completely understand the subject, that that person speaks (always)
truly.
You statement with the sure tone that it's "terrible idea", although,
it's just your (humble.) opinion. Will you mind?
P.S.: Though, all this does not cancel really awful and terrible
ideas ;) I also can use this words when the idea is really terrible.
/ds
Dmitry A. Soshnikov
>And that
> "method" method is ridiculous.
I didn't touch the concrete method(s) of Crockford, I don't mind. I
was talking about the general theory of the augmenting of the built-
ins.
But yep, the "method" method is ridiculous, I agree ;)
/ds
John G Harris
Soshnikov wrote:
>On 3 0
<snip>
>> terrible idea
>> terrible
>> terrible idea
>
>Please, don't use demagogy, propaganda, and
Please don't give such misleading quotes. They are a form of demagogy
and propaganda.
You could have quoted like this :
>> In a Web page, it's generally a terrible idea
<your complaint about 'terrible'>
>>as scripts typically
>> have to co-exist with others.
<your agreement about 'co-exist'>
John
--
John Harris
Dmitry A. Soshnikov
> On Sun, 3 Jan 2010 at 08:38:18, in comp.lang.javascript, Dmitry A.Soshnikov wrote:
> >On 3 0
> <snip>
> >> terrible idea
> >> terrible
> >> terrible idea
>
> >Please, don't use demagogy, propaganda, and
>
> <snip>
>
> Please don't give such misleading quotes. They are a form of demagogy
> and propaganda.
>
Please, pay attention that I used it specially (as a kind of irony) to
show, how it looks. For what reason, I should give in on provocation
and accept such rules when one person statements his humble opinion
with sure tone "That's wrong. That's terrible." (this person tries to
take the main role and to take the dialog in his hands) and the other
one should prove why it's not so (this person is kind of that
justifies). It's direct demagogy which I see and don't wanna accept.
That's it. Objections?
> You could have quoted like this :
>
> >> In a Web page, it's generally a terrible idea
>
> <your complaint about 'terrible'>
>
I know that, thanks.
> >>as scripts typically
> >> have to co-exist with others.
>
> <your agreement about 'co-exist'>
>
I also know that, thanks.
/ds
Jorge
> (...)
> >> as scripts typically
> >> have to co-exist with others.
>
> <your agreement about 'co-exist'>
"agreement" ?
The typicality of that hypothetical coexistence is very debatable.
And, in any case, "others" is !== "unknown scripts". Do you allow
"unknown" code to run in your page ? Does any of these -hypothetical-
cohabitant scripts break anything ? And if they do, why ? Don't their
authors know about .hasOwnProperty() existence and purpose ? Is that
reason enough to ditch .prototype inheritance altogether ? The answer,
in general, is NOT yes. The answer, in general, is of course NOT.
--
Jorge.
David Mark
> On Jan 3, 6:51 pm, John G Harris <j...@nospam.demon.co.uk> wrote:
>
> > (...)
> > >> as scripts typically
> > >> have to co-exist with others.
>
> > <your agreement about 'co-exist'>
>
> "agreement" ?
>
> The typicality of that hypothetical coexistence is very debatable.
That's ludicrous. How many Web pages use a single script from a
single author (well, I know of a few at least). :)
> And, in any case, "others" is !== "unknown scripts". Do you allow
> "unknown" code to run in your page ?
Me? Not typically, no. Am I typical?
> Does any of these -hypothetical-
> cohabitant scripts break anything ?
You are babbling.
> And if they do, why ? Don't their
> authors know about .hasOwnProperty() existence and purpose ?
You truly are a student of Crockford. For about the millionth time,
that method doesn't work in "ancient" browsers like Safari 2. I see
it used without proper feature detection and wonder if the authors
realize their scripts will suddenly halt at that spot. Does that seem
a sound degradation strategy to you?
And of all the miserable JS libraries out there, how many actually
filter for-in loops in any form?
> Is that
> reason enough to ditch .prototype inheritance altogether ?
Does it seem to you that I've "ditched" ".prototype inheritance".
Look again.
> The answer,
> in general, is NOT yes.
> The answer, in general, is of course NOT.
Lucid as always. :)
JR
> 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;
>
> };
I've read the book too, but in my version (2008 in Portuguese) that
function is slightly different, with one very important feature test:
Function.prototype.method = function (name, func) {
if (!this.prototype[name]) {
this.prototype[name] = func;
// I didn't see this return this mentioned above.
}
};
And there is a precautionary note about augmenting types, specially
when the page utilizes different libraries / codes.
I also have not read Douglas recommending this type of thing, but
saying that it was possible to do so, arguing that it could make
improvements in the expressiveness of JavaScript.
However, I must admit that that 'part' of the book is confusing and
can mislead readers about the matter (augmenting types); in other
words, a reader might unwittingly adopt the book's example as a good
practice, what would be a temerity.
> String.method('trim', function() {
> return this.replace(/^\s+|\s+$/g, '');
>
> });
>
> Is this a good thing in your opinion?
No, it isn't, even in case you know exactly what you're doing.
--
JR
Jorge
>
> 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).
"If a web browser is defective, causing errors in the display or
performance of the page, should the page developer struggle to hide
the browser's defects, or should the defects be revealed in hope of
creating market pressure to force the browser maker to make good? By
which approach is humanity better served ?"
> I see
> it used without proper feature detection and wonder if the authors
> realize their scripts will suddenly halt at that spot. Does that seem
> a sound degradation strategy to you?
Yes it is. People should (learn to) not expect a broken browser (e.g.
IEs) to work as if it weren't broken.
> And of all the miserable JS libraries out there, how many actually
> filter for-in loops in any form?
In the first place, why are these miserable libraries in *your* page ?
> > Is that
> > reason enough to ditch .prototype inheritance altogether ?
>
> Does it seem to you that I've "ditched" ".prototype inheritance".
Sort of. Because that's the sole mechanism to extend built-ins /
"augmenting types" (this thread's subject), and you've said:
<quote>
On Jan 3, 7:27 am, David Mark <dmark.cins...@gmail.com> wrote:
> Dear God. That's another step towards the abyss. (...)
>
> > Is this a good thing in your opinion?
>
> No.
</quote>
> (...)
> Lucid as always. :)
You're welcome.
--
Jorge.
Jorge
>
> No, it isn't, even in case you know exactly what you're doing.
Dear God ! Another step towards the abyss ?
--
Jorge.
David Mark
> On Jan 4, 12:21 am, David Mark <dmark.cins...@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. Do the words "progressive
enhancement" (or even "graceful degradation") mean _anything_ to you?
>
> "If a web browser is defective, causing errors in the display or
> performance of the page, should the page developer struggle to hide
> the browser's defects, or should the defects be revealed in hope of
> creating market pressure to force the browser maker to make good? By
> which approach is humanity better served ?"
That's the stupidest thing you've parroted yet. As mentioned, missing
features are not defects. The end-users, who sometimes have no
control over what browser they use (and sometimes no idea of what a
browser is) are hardly going to appreciate such a crusade. If your
script(s) break documents, it indicates that your design is
defective. How can you not see that?
>
> > I see
> > it used without proper feature detection and wonder if the authors
> > realize their scripts will suddenly halt at that spot. Does that seem
> > a sound degradation strategy to you?
>
> Yes it is. People should (learn to) not expect a broken browser (e.g.
> IEs) to work as if it weren't broken.
LOL. So you should just screw all IE users and figure they will be
grateful for the tough love? Are you insane?
>
> > And of all the miserable JS libraries out there, how many actually
> > filter for-in loops in any form?
>
> In the first place, why are these miserable libraries in *your* page ?
They certainly aren't, but if you distribute a script for other Web
developers to use, you can hardly predict what will be mashed up with
it. Some go so far as to combine jQuery, Prototype, Mootools, [insert
broken Flash script here], etc. in one document. That's the current
reality. Get with it or go home. ;)
>
> > > Is that
> > > reason enough to ditch .prototype inheritance altogether ?
>
> > Does it seem to you that I've "ditched" ".prototype inheritance".
>
> Sort of. Because that's the sole mechanism to extend built-ins /
> "augmenting types" (this thread's subject), and you've said:
Think again. Or just try reading before posting obvious falsehoods.
>
> <quote>
> On Jan 3, 7:27 am, David Mark <dmark.cins...@gmail.com> wrote:> Dear God. That's another step towards the abyss. (...)
>
> > > Is this a good thing in your opinion?
>
> > No.
>
> </quote>
Augmenting built-in types is not the only way to leverage prototypal
inheritance.
>
> > (...)
> > Lucid as always. :)
>
> You're welcome.
Beat it, Jorge.
David Mark
Jorge wanna cracker?
JR
The guy asked our opinion. Mine was stated: I'm against type
augmentation although I know it's possible and can increase
expressiveness of JS. That's just an opinion and I can't see how being
prudent would be a step towards the abyss? I believe in "If it isn't
broken, don't fix it.", and "If something can go wrong, it will."
--
JR
Jorge
> On Jan 3, 7:26 pm, Jorge <jo...@jorgechamorro.com> wrote:
>
> > On Jan 4, 12:21 am, David Mark <dmark.cins...@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
Safari 2.0.4 does have .hasOwnProperty()...
--
Jorge.
David Mark
That's as maybe. Now check 2.0.3, then 2.02... Or, simply wake up
and realize it isn't necessary to worry about such trivia.
if (Object.prototype.hasOwnProperty) {
// Your enhancement here
}
Jorge
>
> 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.
--
Jorge.
David Mark
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). One thing about
corporate users, they all have jobs (and the disposable income that
comes with them). And they are known to surf the Internet on
occasion. ;)
Then there is the Little Old Lady from Pasadena who doesn't know what
IE is, let alone FF or the rest. These sites that throw up
admonitions to "upgrade" to FF (it's free!) are simply displaying a
thorough misunderstanding of their medium.
I know you are one of those "JS or die" proponents as well. There are
laws you know. Many handicapped people have JS disabled by necessity
(and some may even use IE). Does the Little Blind Old Lady from
Pasadena want to hear you babble about how her browser sucks? Oddly
enough, many little old ladies (even blind ones) have money (and time)
to spend on the Internet too.
And consider the somewhat similar medium of television. Do you think
for a second that broadcasters would knowingly cripple their
programming for people with "defective" televisions? Why do you think
it took so long for them to pull the plug on over-the-air analog
broadcasts? By your way of thinking, who in the world doesn't have
cable and/or satellite? Now, what would advertisers think of such
thinking? ;)
David Mark
> On Jan 3, 8:17 pm, Jorge <jo...@jorgechamorro.com> wrote:
>
> > On Jan 4, 1:45 am, David Mark <dmark.cins...@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).
Jorge
> On Jan 3, 8:11 pm, Jorge <jo...@jorgechamorro.com> wrote:
>
>
>
>
>
> > On Jan 4, 1:45 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Jan 3, 7:26 pm, Jorge <jo...@jorgechamorro.com> wrote:
>
> > > > On Jan 4, 12:21 am, David Mark <dmark.cins...@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.
David Mark
Not sure how you figure that, but then you are obviously mad. :)
Garrett Smith
> 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;
>>> };
>>>
>>
>> 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/
Thomas 'PointedEars' Lahn
> 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.)
kangax
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
kangax
> 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.
Wrong? Hardly. Incomplete, yes.
A more correct rephrasing would probably be:
None of the built-in functions may be used as a constructor, as none of
them shall implement internal [[Construct]] method (unless specified
explicitly in a corresponding section of specification).
[...]
--
kangax
David Mark
> On 1/3/10 8:43 PM, David Mark wrote:
>
>
>
> > On Jan 3, 8:34 pm, David Mark<dmark.cins...@gmail.com> wrote:
> >> On Jan 3, 8:17 pm, Jorge<jo...@jorgechamorro.com> wrote:
>
> >>> On Jan 4, 1:45 am, David Mark<dmark.cins...@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.
Propose? I've never seen it do anything but throw that obscure error
message at the user. What version/configuration are you talking
about?
And assume if it did. Put yourself in the end-user's chair. You see
a dialog asking if you want to disable scripts on this page. The back
button is the next move for most.
>
> User can choose to disable scripts and proceed with a fully functional
> page/app (that is, if things work without scripting,
And that's a big if, of course. Most users will panic and flee
anyway.
> 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.
Yep. There's no right answer for the user. Most will have no clue
which to choose anyway.
>
> 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.
>
And that's very odd as it has been over a decade since IE6 came out
(and these issues were present IE < 6 as well). Why should such
developers endeavor to shield neophytes from the rigors of cross-
browser scripting (translates to dealing with IE for most
applications) when they can't figure out IE. They had a decade of
relative calm on that front and then... ;)
Thomas 'PointedEars' Lahn
How can something be "more correct" (there is no comparison of "correct")
when it is still obviously wrong?
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Garrett Smith
> On 1/4/10 12:02 AM, 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.
LOL. YOU read the fucking manual.
>
> Wrong? Hardly. Incomplete, yes.
>
> A more correct rephrasing would probably be:
>
> None of the built-in functions may be used as a constructor, as none of
> them shall implement internal [[Construct]] method (unless specified
> explicitly in a corresponding section of specification).
>
You are far too kind.
kangax
> kangax wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Garrett Smith wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Garrett Smith wrote:
>>>>>> Ryan Chan wrote:
>>>>>>> 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.
>>
>> Wrong? Hardly. Incomplete, yes.
>>
>> A more correct rephrasing would probably be:
>>
>> None of the built-in functions may be used as a constructor, as none of
>> them shall implement internal [[Construct]] method (unless specified
>> explicitly in a corresponding section of specification).
>
> How can something be "more correct" (there is no comparison of "correct")
> when it is still obviously wrong?
You can't be serious... I'm sure you can find relevant section in specs
on your own.
--
kangax
kangax
IE7 shows error popup and asks if I want to continue running scripts on
this page.
Something like this �
<http://chadsanswers.com/wp-content/uploads/2009/04/toaster.jpg>, but
different error of course.
[...]
>> 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.
>>
>
> And that's very odd as it has been over a decade since IE6 came out
> (and these issues were present IE< 6 as well). Why should such
> developers endeavor to shield neophytes from the rigors of cross-
> browser scripting (translates to dealing with IE for most
> applications) when they can't figure out IE. They had a decade of
> relative calm on that front and then... ;)
I've been meaning to write about it for some time now. Will do whenever
I get a chance. Perhaps someone will listen.
--
kangax
David Mark
That may depend on the configuration. I know that some versions of IE
spew out the "automation server" message, which is going to scare the
hell out of most users.
>
> Something like this �
> <http://chadsanswers.com/wp-content/uploads/2009/04/toaster.jpg>, but
> different error of course.
Yep, that's a failure alright. ;)
>
> [...]
>
> >> 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.
>
> > And that's very odd as it has been over a decade since IE6 came out
> > (and these issues were present IE< 6 as well). Why should such
> > developers endeavor to shield neophytes from the rigors of cross-
> > browser scripting (translates to dealing with IE for most
> > applications) when they can't figure out IE. They had a decade of
> > relative calm on that front and then... ;)
>
> I've been meaning to write about it for some time now. Will do whenever
> I get a chance. Perhaps someone will listen.
>
Perhaps. :)
David Mark
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.
Thomas 'PointedEars' Lahn
I am dead serious.
> I'm sure you can find relevant section in specs on your own.
The question is: Can you? For the Specification is _not_ clear there, and
implementations vary.
ECMAScript Edition 5 states:
| 15 Standard Built-in ECMAScript Objects
|
| [...]
| None of the built-in functions described in this clause that are not
| constructors shall implement the [[Construct]] internal method unless
| otherwise specified in the description of a particular function. [...]
Mark the wording: "built-in functions that are not constructors". Now,
what *is* a "constructor"?
| 4.3.4
| constructor
| Function object that creates and initialises objects.
But the Specification defines that a "built-in function" is a "built-in
object that is a function." (ES5, 4.3.23), and that a "function (object)"
is a "member of the Object type that is an instance of the standard built-
in Function constructor and that may be invoked as a subroutine." (4.3.22)
There is *nothing* in the Specification that says that Function instances
are not [[Construct]]able by default. In fact, function instances/objects
do have by default an internal [[Construct]] property. (13.2)
But yes, I concur that section 15 casts doubt about whether built-in
methods should be used as constructor; to do that is probably error-prone.
However, in any case the statement "None of the built in functions may be
used as a constructor." is not only incomplete; it is obviously _wrong_.
As the statement is an existential negation, to prove it wrong I need only
one counter-example:
var o = new Object();
HTH
Pointed"new Array.prototype.join()"Ears
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
kangax
Ah, here we go. My fault for not specifying _which edition_ I'm talking
about. And yes, it was actually 3rd one I had in mind (and, I think, the
one Garrett referred to as well, since me and him already had
conversation over at es-discuss on the very same subject, back in
November �
<https://mail.mozilla.org/pipermail/es-discuss/2009-November/010162.html>).
>
> | 15 Standard Built-in ECMAScript Objects
> |
> | [...]
> | None of the built-in functions described in this clause that are not
> | constructors shall implement the [[Construct]] internal method unless
> | otherwise specified in the description of a particular function. [...]
>
> Mark the wording: "built-in functions that are not constructors". Now,
> what *is* a "constructor"?
This "...is not constructor..." addition clearly confuses matters here.
Compare to wording from 3rd edition:
"None of the built-in functions described in this section shall
implement the internal [[Construct]] method unless otherwise specified
in the description of a particular function."
>
> | 4.3.4
> | constructor
> | Function object that creates and initialises objects.
So, if built-in function doesn't create or initialize an object, it
shall not implement [[Construct]]. Isn't that what follows from:
1) None of the built-in functions described in this clause that are not
constructors shall implement the [[Construct]] internal method
2) construct is a Function object that creates and initialises (sic)
objects.
>
> But the Specification defines that a "built-in function" is a "built-in
> object that is a function." (ES5, 4.3.23), and that a "function (object)"
> is a "member of the Object type that is an instance of the standard built-
> in Function constructor and that may be invoked as a subroutine." (4.3.22)
>
> There is *nothing* in the Specification that says that Function instances
> are not [[Construct]]able by default. In fact, function instances/objects
> do have by default an internal [[Construct]] property. (13.2)
Aren't we talking about built-in functions? What do Function instances
have to do with this? Yes, Function instances have [[Construct]] but
built-in functions have their own "rules" and own preceding section
explaining exact semantics.
>
> But yes, I concur that section 15 casts doubt about whether built-in
> methods should be used as constructor; to do that is probably error-prone.
>
> However, in any case the statement "None of the built in functions may be
> used as a constructor." is not only incomplete; it is obviously _wrong_.
> As the statement is an existential negation, to prove it wrong I need only
> one counter-example:
>
> var o = new Object();
How is this a proof?
"...unless otherwise specified in the description of a particular
function" clause (from what you cited above) allows this.
[...]
--
kangax
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> kangax wrote:
>> There is *nothing* in the Specification that says that Function
>> instances are not [[Construct]]able by default. In fact, function
>> instances/objects do have by default an internal [[Construct]]
>> property. (13.2)
>
> Aren't we talking about built-in functions? What do Function instances
> have to do with this?
If you had cared to read the definitions I quoted ...
>> However, in any case the statement "None of the built in functions may
>> be used as a constructor." is not only incomplete; it is obviously
>> _wrong_. As the statement is an existential negation, to prove it
>> wrong I need only one counter-example:
>>
>> var o = new Object();
>
> How is this a proof?
`Object' is a built-in function.
> "...unless otherwise specified in the description of a particular
> function" clause (from what you cited above) allows this.
Irrelevant, that was not in the original (Garrett's) statement.
Apparently your logic module is borken after all.
Eric Bednarz
> On Jan 3, 1:50 pm, Jorge <jo...@jorgechamorro.com> wrote:
>> authors know about .hasOwnProperty() existence and purpose ?
>
> You truly are a student of Crockford. For about the millionth time,
> that method doesn't work in "ancient" browsers like Safari 2.
It works in Safari 2.04; I would expect that people who are stuck with
OS X 10.4 would still run system updates.
> I see
> it used without proper feature detection
Booo! :-)
Thomas 'PointedEars' Lahn
> And I think it bears pointing out that there is no recovery from
> [an "automation server can't create object ..."] exception.
Wrong, try-catch can handle this.
Jorge
That user defined properties -inherited or not- are enumerable isn't
something to be afraid of, and String.prototype.trim() is a good
example of handiness that can't break anything. If it broke a certain
script, the culprit would be that script's author's ignorance, but
instead you and Mark are mistakenly pointing at a nice feature of the
language as the culprit and advocating to mutilate it... ¿?
--
Jorge.
Thomas 'PointedEars' Lahn
> JR wrote:
>> Jorge wrote:
>> > JR wrote:
>> >> No, it isn't, even in case you know exactly what you're doing.
>> >
>> > Dear God ! Another step towards the abyss ?
>>
>> The guy asked our opinion. Mine was stated: I'm against type
>> augmentation although I know it's possible and can increase
>> expressiveness of JS. That's just an opinion and I can't see
>> how being prudent would be a step towards the abyss?
Because your opinion expressed above is not based on prudence but on
irrational fear instead. It goes without saying that if one knows exactly
what they are doing, they must also be aware of the side-effects.
>> I believe in "If it isn't broken, don't fix it.",
In a way, a trim() prototype method present in one implementation and not
in another is something that is borken in the latter because it would
require a different approach in the main code.
On a second thought, one might also want to program non-interoperabilities
out of the trim() implementation which is a goal worth pursuing despite the
reduced efficiency of the user-defined code.
>> and "If something can go wrong, it will."
Fear is a bad advisor.
> That user defined properties -inherited or not- are enumerable isn't
> something to be afraid of,
But to be kept in mind.
> and String.prototype.trim() is a good example of handiness that can't
> break anything.
That is, if it is done properly, contrary to the example. For it is rather
unlikely that anyone would plainly for-in iterate over String instances or
values without general property detection or side-effects in mind.
> If it broke a certain script, the culprit would be that script's
> author's ignorance, but instead you and Mark are mistakenly pointing
> at a nice feature of the language as the culprit and advocating to
> mutilate it... ¿?
ACK
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
JR
> Jorge wrote:
> > JR wrote:
> >> Jorge wrote:
> >> > JR wrote:
> >> >> No, it isn't, even in case you know exactly what you're doing.
>
> >> > Dear God ! Another step towards the abyss ?
>
> >> The guy asked our opinion. Mine was stated: I'm against type
> >> augmentation although I know it's possible and can increase
> >> expressiveness of JS. That's just an opinion and I can't see
> >> how being prudent would be a step towards the abyss?
>
> Because your opinion expressed above is not based on prudence but on
> irrational fear instead. It goes without saying that if one knows exactly
> what they are doing, they must also be aware of the side-effects.
No, it's prudence against the many that *think* they know what they're
doing.
> >> I believe in "If it isn't broken, don't fix it.",
>
> In a way, a trim() prototype method present in one implementation and not
> in another is something that is borken in the latter because it would
> require a different approach in the main code.
Why this insistence on the term 'borken'? Why not writing broken?
> On a second thought, one might also want to program non-interoperabilities
> out of the trim() implementation which is a goal worth pursuing despite the
> reduced efficiency of the user-defined code.
>
> >> and "If something can go wrong, it will."
>
> Fear is a bad advisor.
The cemetery is full of fearless men.
> > That user defined properties -inherited or not- are enumerable isn't
> > something to be afraid of,
>
> But to be kept in mind.
>
> > and String.prototype.trim() is a good example of handiness that can't
> > break anything.
>
> That is, if it is done properly, contrary to the example. For it is rather
> unlikely that anyone would plainly for-in iterate over String instances or
> values without general property detection or side-effects in mind.
>
> > If it broke a certain script, the culprit would be that script's
> > author's ignorance, but instead you and Mark are mistakenly pointing
> > at a nice feature of the language as the culprit and advocating to
> > mutilate it... ¿?
>
> ACK
No, you are mistaken. Read again: I did not advise anyone to
'mutilate' JS, instead I commented (as an opinion, of course) to not
use the 'augmenting-types' capability, given the context mentioned
earlier in the same post [Douglas Crockford's note about the need of
being careful when there are other scripts in the page]. "Not to use
something" is totally different from "mutilating something".
--
JR
Jorge
http://dev.rubyonrails.org/ticket/9700
(Both have it too)
--
Jorge.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Jorge wrote:
>> > JR wrote:
>> >> Jorge wrote:
>> >> > JR wrote:
>> >> >> No, it isn't, even in case you know exactly what you're doing.
>>
>> >> > Dear God ! Another step towards the abyss ?
>>
>> >> The guy asked our opinion. Mine was stated: I'm against type
>> >> augmentation although I know it's possible and can increase
>> >> expressiveness of JS. That's just an opinion and I can't see
>> >> how being prudent would be a step towards the abyss?
>>
>> Because your opinion expressed above is not based on prudence but on
>> irrational fear instead. It goes without saying that if one knows
>> exactly what they are doing, they must also be aware of the side
>> effects.
>
> No, it's prudence against the many that *think* they know what they're
> doing.
That is a non sequitur. Why support incompetence?
>> On a second thought, one might also want to program
>> non-interoperabilities out of the trim() implementation which is a goal
>> worth pursuing despite the reduced efficiency of the user-defined code.
>>
>> >> and "If something can go wrong, it will."
>>
>> Fear is a bad advisor.
>
> The cemetery is full of fearless men.
False analogy.
>> > That user defined properties -inherited or not- are enumerable isn't
>> > something to be afraid of,
>>
>> But to be kept in mind.
>>
>> > and String.prototype.trim() is a good example of handiness that can't
>> > break anything.
>>
>> That is, if it is done properly, contrary to the example. For it is
>> rather unlikely that anyone would plainly for-in iterate over String
>> instances or values without general property detection or side-effects
>> in mind.
>>
>> > If it broke a certain script, the culprit would be that script's
>> > author's ignorance, but instead you and Mark are mistakenly pointing
>> > at a nice feature of the language as the culprit and advocating to
>> > mutilate it... ¿?
>>
>> ACK
>
> No, you are mistaken.
I am not.
> Read again: I did not advise anyone to 'mutilate' JS, instead I commented
> (as an opinion, of course) to not use the 'augmenting-types' capability,
> given the context mentioned earlier in the same post [Douglas Crockford's
> note about the need of being careful when there are other scripts in the
> page].
In this very example augmenting the prototype object can do no harm at all
except to those who are stupid enough to for-in over String instances or
values without considering enumerable properties. Your categorical "do not
use" principle is in effect shifting the responsibility entirely from the
library user to the library author. Have you not seen enough inefficient
jQuery nonsense to see that this is a flawed concept?
> "Not to use something" is totally different from "mutilating something".
I was not referring to that part or to your statements in particular there.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Scott Sauyet
> I've read the book too, but in my version (2008 in Portuguese) that
> function is slightly different, with one very important feature test:
My English copy of the book (2008, first edition) lists the OP's
version of the code, and then later in the same section lists the one
you supply, introduced by "The prototypes of the basic types are
public structures, so care must be taken when mixing libraries. One
defensive technique is to add a method only if the method is known to
be missing."
> Function.prototype.method = function (name, func) {
> if (!this.prototype[name]) {
> this.prototype[name] = func;
> }
> };
Clearly this is an improvement on the original. I agree with whoever
mentioned that this should have a verb, "setMethod", "addMethod", or
some such.
I don't much like modifying the prototypes of the built-in objects,
although I understand that it can be useful and powerful to do so in
at least some circumstances. But Crockford's only justification for
this is only that "[W]e no longer have to type the name of the
prototype property. That bit of ugliness can now be hidden." His
original version (as supplied by the OP) seems to have no advantage.
I certainly don't see that this:
Number.method('integer', function () {
return Math[this < 0 : 'ceil' : 'floor'](this);
});
is any less ugly than this:
Number.prototype.integer = function () {
return Math[this < 0 : 'ceil' : 'floor'](this);
};
But when you add in the error checking, it is clearly less ugly than
this:
if (!Number.prototype.integer) {
Number.prototype.integer = function () {
return Math[this < 0 : 'ceil' : 'floor'](this);
};
}
So I think a version of this technique would be useful if you do
choose to enhance these prototypes.
-- Scott
JR
Brilliant! ITA.
Cheers,
JR
Garrett Smith
> David Mark <dmark....@gmail.com> writes:
>
>> On Jan 3, 1:50 pm, Jorge <jo...@jorgechamorro.com> wrote:
>
>>> authors know about .hasOwnProperty() existence and purpose ?
>> You truly are a student of Crockford. For about the millionth time,
>> that method doesn't work in "ancient" browsers like Safari 2.
>
> It works in Safari 2.04; I would expect that people who are stuck with
> OS X 10.4 would still run system updates.
>
Ah but 10.4 can get Safari 3 and 4. 10.3 users are a different matter.
Now for 10.3, you'd need to support Safari 1. I do know any way to test
Safari 1 on 10.4.
Apple bundles the Browser with the operating system, but somehow does
not suffer the legal troubles that Microsoft has experienced in doing
the same. Apple does a lot worse things and gets away with those, too.
Apple a good example what is wrong with business in America.
John G Harris
Soshnikov wrote:
>On 3 0
<snip>
>> You could have quoted like this :
>>
>> >> In a Web page, it's generally a terrible idea
>>
>> � <your complaint about 'terrible'>
>>
>
>I know that, thanks.
If you know that then why did you make it look as though David wrote the
word 'terrible' four times ?
>> >>as scripts typically
>> >> have to co-exist with others.
>>
>> � <your agreement about 'co-exist'>
>>
>
>I also know that, thanks.
John
--
John Harris
Dmitry A. Soshnikov
> On Sun, 3 Jan 2010 at 10:18:43, in comp.lang.javascript, Dmitry A.
>
> Soshnikov wrote:
> >On 3 0
> <snip>
> >> You could have quoted like this :
>
> >> >> In a Web page, it's generally a terrible idea
>
> >> <your complaint about 'terrible'>
>
> >I know that, thanks.
>
> If you know that then why did you make it look as though David wrote the
> word 'terrible' four times ?
>
I've already answered to you. Should I repeat twice? Please ask if
something still unclear, I will.
/ds
Jorge
> Eric Bednarz wrote:
>
> > It works in Safari 2.04; I would expect that people who are stuck with
> > OS X 10.4 would still run system updates.
>
> Ah but 10.4 can get Safari 3 and 4. 10.3 users are a different matter.
10.3 users can install FF2 or iCab 3 or iCab 4 or Opera 8 or 9 or 10,
or ...
> Now for 10.3, you'd need to support Safari 1. I do know any way to test
> Safari 1 on 10.4.
Safari 1 is as obsolete as IE5. There's no need to support that (see
above the plenty of alternative options that 10.3 users have)
> Apple bundles the Browser with the operating system, but somehow does
> not suffer the legal troubles that Microsoft has experienced in doing
> the same.
Only that to uninstall Safari all you need to do is to trash its icon,
and doing that won't "damage the operating system" -as used to be the
case when uninstalling IE- (http://en.wikipedia.org/wiki/
United_States_v._Microsoft and http://en.wikipedia.org/wiki/Removal_of_Internet_Explorer).
And the OSX APIs that Safari uses are public so that other browser
makers can use them too (unlike the IE/Windows combo), and that
Safari's source code is open, public and free. And that Apple's OSs up
to OSX (year 2001), came with both IE and NetScape Navigator installed
by default.
> Apple does a lot worse things and gets away with those, too. Apple a good example what is wrong with business in America.
People's idiocy in general (and some people's idiocy in particular) is
much worse a problem currently than Apple's business practices. BTW,
here's some -hot- dirty play being made to Apple, see see:
http://stadium.weblogsinc.com/engadget/files/apple-nokia-answer.pdf
--
Jorge.
Matt Kruse
> Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
> Augmenting Types, e.g.
> return this.replace(/^\s+|\s+$/g, '');
> });
There have been a number of replies. I'll just post some pros/cons to
adding the methods _only if they don't already exist_:
PRO:
1) Consistent API defined by specs, not some additional list of
functions developers need to learn
2) Native method used if it already exists, so you take advantage of
browser optimizations
3) As browsers are upgraded and fast native methods are added, they
will automatically be used without changing your code
CON:
1) Other code on your page may break due to naive "feature tests" and
object inferences that you have now corrected, or dumb for loops that
iterate over your added properties.
2) User-defined functionality may not exactly match the browser's
native functionality.
3) Browsers without the method may be upgraded to add the method, but
add bugs or quirks and make it _worse_ than the user-defined function
and/or break functionality.
4) Other code on your page may choose to do the same thing, but use
different logic than you. You won't be sure if your methods have been
"stepped on" and replaced.
5) You're likely delivering a lot of code to define methods in
browsers that may not need any of it because native methods already
exist.
Of course, if you over-write methods even if they exist you may get
consistent user-defined behavior across all browsers, but you lose
native methods and open yourself up to introducing bugs, so that isn't
a good idea.
CONCLUSION:
I think that implementing a few methods that are in the standards and
add convenience but may not exist in older browsers is not a bad idea.
However, you shouldn't have a single file that you include everywhere
that implements every known method that may be lacking, because that's
a waste of bytes and processing for browsers that don't need it. Just
implement the methods you'll be using on the page where you want them,
if possible.
Matt Kruse
David Mark
wrote:
> David Mark wrote:
> > And I think it bears pointing out that there is no recovery from
> > [an "automation server can't create object ..."] exception.
>
> Wrong, try-catch can handle this.
>
You misquoted me. (!) Are you kidding? You know exactly what I was
referring to (if not, see screen shot). Obviously the error was _not_
caught by try-catch, therefore there is no possible recovery
(regardless of the wording of the dialog in the screen shot). Clear?
David Mark
> David Mark <dmark.cins...@gmail.com> writes:
> > On Jan 3, 1:50 pm, Jorge <jo...@jorgechamorro.com> wrote:
> >> authors know about .hasOwnProperty() existence and purpose ?
>
> > You truly are a student of Crockford. For about the millionth time,
> > that method doesn't work in "ancient" browsers like Safari 2.
>
> It works in Safari 2.04; I would expect that people who are stuck with
> OS X 10.4 would still run system updates.
So say it was 2.01 (or whatever). It's irrelevant as Safari 2 is not
the only browser without that method.
>
> > I see
> > it used without proper feature detection
>
> Booo! :-)
Huh? Using it without detecting it means the script blows up,
possibly leaving the document in an unusable state. Scripts are not
allowed to die without permission.
That's always been the point (and it's a good one). ;)
David Mark
> > And I think it bears pointing out that there is no recovery from
> > [an "automation server can't create object ..."] exception.
>
> Wrong, try-catch can handle this.
>
You misquoted me. (!) Are you kidding? You know exactly what I was
Eric Bednarz
> Eric Bednarz wrote:
[.hasOwnProperty() in Safari 2]
>> It works in Safari 2.04; I would expect that people who are stuck with
>> OS X 10.4 would still run system updates.
>
> Ah but 10.4 can get Safari 3 and 4. 10.3 users are a different matter.
My mistake, thanks for the correction.
> Apple bundles the Browser with the operating system, but somehow does
> not suffer the legal troubles that Microsoft has experienced in doing
> the same. Apple does a lot worse things and gets away with those, too.
Compared to Adobe, Apple is a socialistic summer camp.
> Apple a good example what is wrong with business in America.
Business in America suffers from faulty ECMAScript implementations?
Eric Bednarz
> Eric Bednarz wrote:
>> David Mark <dmark.cins...@gmail.com> writes:
>>> that method [hasOwnProperty] doesn't work in "ancient" browsers like
>>> Safari 2.
>>
>> It works in Safari 2.04; […]
>
> So say it was 2.01 (or whatever). It's irrelevant as Safari 2 is not
> the only browser without that method.
I know, but it is not my fault that you picked a bad example ;-)
>>> I see
>>> it used without proper feature detection
>>
>> Booo! :-)
>
> Huh?
It was more of a general ‘no kidding’-booo.
> Using it without detecting it means the script blows up,
> possibly leaving the document in an unusable state.
Sure, but there are worse things around that blow up scripts in much
more common setups. Well, I don’t need to tell you that.
David Mark
> David Mark <dmark.cins...@gmail.com> writes:
> > Eric Bednarz wrote:
> >> David Mark <dmark.cins...@gmail.com> writes:
> >>> that method [hasOwnProperty] doesn't work in "ancient" browsers like
> >>> Safari 2.
>
> >> It works in Safari 2.04; […]
>
> > So say it was 2.01 (or whatever). It's irrelevant as Safari 2 is not
> > the only browser without that method.
>
> I know, but it is not my fault that you picked a bad example ;-)
>
I don't think it was a bad example. I contend that some revision of
Safari 2 is lacking that method (though it remains to be seen which
one).
> >>> I see
> >>> it used without proper feature detection
>
> >> Booo! :-)
>
> > Huh?
>
> It was more of a general ‘no kidding’-booo.
Oh.
>
> > Using it without detecting it means the script blows up,
> > possibly leaving the document in an unusable state.
>
> Sure, but there are worse things around that blow up scripts in much
> more common setups. Well, I don’t need to tell you that.
:)
Garrett Smith
> Garrett Smith <dhtmlk...@gmail.com> writes:
>
>> Eric Bednarz wrote:
>
> [.hasOwnProperty() in Safari 2]
>
>>> It works in Safari 2.04; I would expect that people who are stuck with
>>> OS X 10.4 would still run system updates.
>> Ah but 10.4 can get Safari 3 and 4. 10.3 users are a different matter.
>
> My mistake, thanks for the correction.
>
>> Apple bundles the Browser with the operating system, but somehow does
>> not suffer the legal troubles that Microsoft has experienced in doing
>> the same. Apple does a lot worse things and gets away with those, too.
>
> Compared to Adobe, Apple is a socialistic summer camp.
>
Well I don't know much about Adobe.
>> Apple a good example what is wrong with business in America.
>
> Business in America suffers from faulty ECMAScript implementations?
No, business in America is driven by marketing and facilitated by laywers.
Apple lies to the consumers about the technology. Makes an
web-incompatible browser, patents the incompatibility, prevents other
browser competition on iPhone.
The word "advertisement" comes from latin. The root word "advertise"
means "turn toward".
kangax
> On Jan 4, 7:32 pm, Eric Bednarz<bedn...@fahr-zur-hoelle.org> wrote:
>> David Mark<dmark.cins...@gmail.com> writes:
>>> Eric Bednarz wrote:
>>>> David Mark<dmark.cins...@gmail.com> writes:
>>>>> that method [hasOwnProperty] doesn't work in "ancient" browsers like
>>>>> Safari 2.
>>
>>
>>> So say it was 2.01 (or whatever). It's irrelevant as Safari 2 is not
>>> the only browser without that method.
>>
>> I know, but it is not my fault that you picked a bad example ;-)
>>
>
> I don't think it was a bad example. I contend that some revision of
> Safari 2 is lacking that method (though it remains to be seen which
> one).
Safari 2.0 and lower (such as 1.3.2 � latest from 1.x series) lacks
`hasOwnProperty`. Next version � 2.0.2 already has it, so do 2.0.3 and
last from 2.x series � 2.0.4.
IIRC, IE introduced `hasOwnProperty` starting with 5.5, so 5.0 and lower
don't have it. Early versions of Konqueror might lack it too, I don't
know. And of course mobile non-modern browsers usually have poor
support, so it could be missing there as well.
[...]
--
kangax
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>> > And I think it bears pointing out that there is no recovery from
>> > [an "automation server can't create object ..."] exception.
>>
>> Wrong, try-catch can handle this.
>
> You misquoted me. (!)
Apparently, out of misunderstanding what you were referring to.
> Are you kidding?
No.
> You know exactly what I was referring to
Apparently I did not know it.
> (if not, see screen shot).
ACK
> 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.
> therefore there is no possible recovery (regardless of the wording
> of the dialog in the screen shot). Clear?
No, non sequitur until now.
David Mark
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> David Mark wrote:
> >> > And I think it bears pointing out that there is no recovery from
> >> > [an "automation server can't create object ..."] exception.
>
> >> Wrong, try-catch can handle this.
>
> > You misquoted me. (!)
>
> Apparently, out of misunderstanding what you were referring to.
Yes, I was a little vague. The whole point was that there was no try-
catch. That's why jQuery drops dead in a lot of corporate
environments.
>
> > Are you kidding?
>
> No.
>
> > You know exactly what I was referring to
>
> Apparently I did not know it.
>
> > (if not, see screen shot).
>
> ACK
>
> > 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. Kangax had
mentioned about the _wording_ of the dialog, which seems to indicate
that the application (or enhancement) can recover from the exception
(by allowing IE to run other scripts on the page).
Thomas 'PointedEars' Lahn
> Eric Bednarz wrote:
>> David Mark <dmark....@gmail.com> writes:
>>> On Jan 3, 1:50 pm, Jorge <jo...@jorgechamorro.com> wrote:
>>>> authors know about .hasOwnProperty() existence and purpose ?
>>> You truly are a student of Crockford. For about the millionth time,
>>> that method doesn't work in "ancient" browsers like Safari 2.
>>
>> It works in Safari 2.04; I would expect that people who are stuck with
>> OS X 10.4 would still run system updates.
>
> Ah but 10.4 can get Safari 3 and 4. 10.3 users are a different matter.
>
> Now for 10.3, you'd need to support Safari 1. I do know any way to test
> Safari 1 on 10.4.
That is, you do _not_ know any?
Anyhow, Mac OS X 10.3 users would probably prefer IE 5 for Mac or Mozilla
Camino over Safari 1 these days, so I would not bother with optimizing for
the latter anymore.
Thomas 'PointedEars' Lahn
> 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.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
David Mark
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. It would be
pretty ludicrous if it weren't (almost as ludicrous as not using a try-
catch when instantiating an ActiveX object). ;)
Thomas 'PointedEars' Lahn
> 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?
> 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...@a6g2000yqm.googlegroups.com>
that "there is no recovery from such an exception."
Something does not add up here.
David Mark
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.
>
> > 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...@a6g2000yqm.googlegroups.com>
> that "there is no recovery from such an exception."
>
> Something does not add up here.
>
An _uncaught_ exception. The message on the dialog in the screen shot
was supposedly good news for "such exceptions." I was pointing out
that it was not (i.e. it would not magically recover on clicking
"No"). Clear now?
Thomas 'PointedEars' Lahn
> 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...@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.
David Mark
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?
Thomas 'PointedEars' Lahn
> 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...@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.
David Mark
Not in the case of ActiveX instantiation (which is what we were
talking about). Nor is there an "Object Expected" error that foils
try-catch that I know of either (but that's beside the point).
>
> > 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.
>
> > 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. As I said, it would be _ludicrous_ if MS did not
allow you to catch such exceptions (given the fact that the component
may not be available).
>
> > 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.
I miss no such thing. In the context we are discussing (ActiveX
object instantiation), it does not apply.
>
> > Now are we clear on what is a completely moot point?
>
> Not at all.
Shit.
>
> >> > 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?
Too late for the script in question to go on about its merry way.
>
> > 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.
>
> > 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.
>
> > (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_).
>
> > The original aside was to alleviate any confusion that _beginners_ may
> > have with the wording in the screen shot.
>
> Maybe so.
Not maybe. I know why I wrote it. :)
>
> > 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.
Garrett Smith
> Garrett Smith wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>>> Ryan Chan wrote:
>>>>> Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
>>>>> Augmenting Types, e.g.
>>>>>
>>>>> 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.
Thomas 'PointedEars' Lahn
> 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...@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.
> Nor is there an "Object Expected" error that foils
> try-catch that I know of either (but that's beside the point).
No, that *is* the point.
>> > 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)?
Obvious answer: You can _not_; you are wrong, and the example is
inappropriate.
>> > 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.
> As I said, it would be _ludicrous_ if MS did not allow you to catch such
> exceptions
And I do not concur.
> (given the fact that the component may not be available).
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.
>
> I miss no such thing. In the context we are discussing (ActiveX
> object instantiation), it does not apply.
Why the inappropriate example then?
>> > Now are we clear on what is a completely moot point?
>> Not at all.
>
> Shit.
Happens.
>> >> > 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?
>
> Too late for the script in question to go on about its merry way.
Is there any proof for your assumption?
>> > 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.
>> > 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.
>> > (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.
>> > 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.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
David Mark
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...@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. :)
>
> > Nor is there an "Object Expected" error that foils
> > try-catch that I know of either (but that's beside the point).
>
> No, that *is* the point.
*Sigh* See above.
>
> >> > 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.
>
> Obvious answer: You can _not_; you are wrong, and the example is
> inappropriate.
>
> >> > 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. It's irrelevant and how can you keep harping on it
after all of this discussion?
>
> > 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?
>
> > (given the fact that the component may not be available).
>
> Non sequitur.
I really dislike this sort of endless arguing about nothing.
>
> >> > 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.
>
> >> > Now are we clear on what is a completely moot point?
> >> Not at all.
>
> > Shit.
>
> Happens.
Yes.
>
>
>
> >> >> > 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?
>
> > 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?
>
> >> > 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.
>
> >> > 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.
>
> >> > (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.
>
> >> > 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?
Thomas 'PointedEars' Lahn
> 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?
Thomas 'PointedEars' Lahn
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.
Jorge
> (...)
> 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.
David Mark
[...]
>
> 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!
Thomas 'PointedEars' Lahn
[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...@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").
Jorge
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.
Garrett Smith
What is confusing about that?
Garrett Smith
Which identifier at the end of the scope chain?
Here is the example one more time:
| 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;
| }())
John G Harris
Soshnikov wrote:
>On 4 0 >> On Sun, 3 Jan 2010 at 10:18:43, in comp.lang.javascript, Dmitry A.
>>
>> Soshnikov wrote:
>> >On 3 0
>> <snip>
>> >> You could have quoted like this :
>>
>> >> >> In a Web page, it's generally a terrible idea
>>
>> >> <your complaint about 'terrible'>
>>
>> >I know that, thanks.
>>
>> If you know that then why did you make it look as though David wrote the
>> word 'terrible' four times ?
>>
>
>I've already answered to you. Should I repeat twice? Please ask if
>something still unclear, I will.
You said it was ironical. You still haven't said why you used quote
markers to make it look like David wrote something four times in his
article. That's forgery, as an aid to demagogy.
John
--
John Harris
Garrett Smith
> Garrett Smith wrote:
>
>>> On Jan 5, 8:07 am, Garrett Smith <dhtmlkitc...@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 ?
>> Accessing properties off the global object is slower than accessing
>> properties off a user defined object.
>>
>> What is confusing about that?
>
It's a question, not a statement.
>
> As a result, accessing the global object directly (with `this' where the
> `this' value is fitting) is actually *faster* than accessing the user-
> defined object if the user-defined object is being referred to by a
> property of the global object (and it cannot get any higher in the
> aggregation tree than that), because one property access less (i.e., none)
> is necessary then.
>
The example code is not using `this` because it makes no sense. o you
have criticism for the example code or ?
> That said, in your example code (hopefully not also in APE) you are not
> even accessing the global object but a poor substitute for it, a host
> object that either mirrors the global object's properties or (more likely)
> has the global object in its prototype chain. So you are not exactly in a
> position to lecture anyone about "accessing properties off global object",
> whatever that gibberish is supposed to mean.
>
I'm not interested in having discussion with one who calls gibberish and
reads questions as statements and certainly not interested your
fantasies about me being in positions.
Jorge
Ok, Garret, excuse me. I misread the code.
Yes, accessing window seems to take slightly longer than accessing {}.
I hope you're aware that p["d.bX.c.d"] has nothing to do with
p.d.bX.c.d, yes ?
--
Jorge.
Thomas 'PointedEars' Lahn
Jorge
>
> Apple lies to the consumers about the technology.
Could you please elaborate ?
> Makes a web-incompatible browser
Which is ... ?
> patents the incompatibility
You probably mean the touch/gestures iPhone JS API ?
> prevents other
> browser competition on iPhone.
Here's a thought: design from scratch, build and try to sell your own
"smartphone". Then allow your competitors to put their software in
(Flash comes to my mind) so that you risk loosing control over your
own invention. Bright idea, yeah.
> The word "advertisement" comes from latin. The root word "advertise"
> means "turn toward".
And the saying think before you talk means exactly what it says.
Cheers,
--
Jorge.
Garrett Smith
I though so.
The only global identifier is `Date`, but that exists in both cases.
Regardless, aliasing `Date` locally makes sense.
> Yes, accessing window seems to take slightly longer than accessing {}.
> I hope you're aware that p["d.bX.c.d"] has nothing to do with
> p.d.bX.c.d, yes ?
You're right. The property is weird.
The reason for using that weird property name is have a fair comparison
on a level field with speed test for the namespace function. The same
name property assignment was copied from the other tests.
Testing property access using no concatenation would read simpler, and
would test purely property access speed, but would not compare as well
to the `namespace` tests, which use some concatenation.
The test for the namespace function uses a long concatenation, and so I
used the exact same string.
A more pure property-access test would not perform any string concatenation.
Thomas 'PointedEars' Lahn
No, `window' is supposed to be a property of the global object, too.
>> Yes, accessing window seems to take slightly longer than accessing {}.
>> I hope you're aware that p["d.bX.c.d"] has nothing to do with
>> p.d.bX.c.d, yes ?
>
> You're right. The property is weird.
>
> The reason for using that weird property name is have a fair comparison
> on a level field with speed test for the namespace function. The same
> name property assignment was copied from the other tests.
The comparison is _not_ fair because `window' is not a (safe) reference to
the global object.
I had only cancelled my follow-up (that you had replied to anyway two hours
later) because I observed, to my surprise, that `this' referring to the
global object was (about 50%) slower than `global' where `global' was a
property of the global object (even if it stored a reference to the global
object) in Firebug (to which might the difference might be attributed; I
would set up a Firebug-unrelated test case then).
The rest of my points still apply for other cases than this: What matters
here is _not_ whether the object-referring property is one of the global
object but in how deep an execution context it is used (i.e., the length of
the effective scope chain) and how many property accesses are necessary to
retrieve the reference (i.e., the number of components -- and maybe the
length of the expression, too, considering how hash tables work -- in the
property accessor expression).
Jorge
>
> Here's a thought: design from scratch, build and try to sell your own
> "smartphone". Then allow your competitors to put their software in
> (Flash comes to my mind) so that you risk loosing control over your
> own invention. Bright idea, yeah.
You ought to see what Larry Ellison says near the end (-5m40s) of the
2nd chapter of "the triumph of the nerds" about the "single worst
mistake in history" IBM did with regards to the PC. Really.
--
Jorge.