Augmenting Types

E

Eric Bednarz

David Mark said:
Eric Bednarz wrote:
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 ;-)

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.
 
D

David Mark

David Mark said:
Eric said:
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).
It was more of a general ‘no kidding’-booo.
Oh.


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.

:)
 
G

Garrett Smith

Eric said:
Garrett Smith said:
Eric Bednarz wrote:

[.hasOwnProperty() in Safari 2]
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.
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".
 
T

Thomas 'PointedEars' Lahn

David said:
Thomas said:
David said:
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.


PointedEars
 
D

David Mark

David said:
Thomas said:
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.
Apparently I did not know it.


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).
 
T

Thomas 'PointedEars' Lahn

Garrett said:
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.


PointedEars
 
T

Thomas 'PointedEars' Lahn

David said:
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
 
D

David Mark

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). ;)
 
T

Thomas 'PointedEars' Lahn

David said:
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
<that "there is no recovery from such an exception."

Something does not add up here.


PointedEars
 
D

David Mark

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.
So you say this exception is catchable, yet you said in
<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?
 
T

Thomas 'PointedEars' Lahn

David said:
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?
An _uncaught_ exception.

Again, how can you possibly know?
The message on the dialog in the screen shot
was supposedly good news for "such exceptions."
Yes.

I was pointing out that it was not (i.e. it would not
magically recover on clicking "No"). Clear now?

No, for there is a "Yes" button which facilitates the recovery.


PointedEars
 
D

David Mark

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?



Again, how can you possibly know?

Because the browser threw up an error message? And because we were
talking about instantiating an ActiveX object. If a try-catch was
used, the exception would have been caught. Conversely, if no try-
catch was used (as with jQuery), the exception will not be caught.
Now are we clear on what is a completely moot point?
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?
 
T

Thomas 'PointedEars' Lahn

You did not answer that question.
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 "Yes" button doesn't recover anything. The execution has _dropped
dead_ at that point (i.e. if you can see the exception dialog, it's
too late). ;)

Too late for what exactly? Is this all mere assumption?
Other scripts can try to get by after that,

Define: other scripts
but it is unlikely they will succeed

How so? They could use completely different references.
(and I can't believe I'm writing all of this again).

You better believe it. As for "again": Message-ID for some *facts*?
The original aside was to alleviate any confusion that _beginners_ may
have with the wording in the screen shot.

Maybe so.
Why are you muddying the waters like this?

On the contrary, I seek clarity on what has already been muddied by you.


PointedEars
 
D

David Mark

You did not answer that question.



No, AISB that is a misconception.

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).
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.
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).
Non sequitur.


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.
Not at all.
Shit.



Too late for what exactly?  Is this all mere assumption?

Too late for the script in question to go on about its merry way.
Define: other scripts

"Other scripts on the page" as mentioned on the dialog in question.
This really is a ludicrous discussion at this point.
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.
You better believe it.  As for "again": Message-ID for some *facts*?

Parse error (and I can't believe I said _that_).
Maybe so.

Not maybe. I know why I wrote it. :)
On the contrary, I seek clarity on what has already been muddied by you.

Well, it isn't working.
 
G

Garrett Smith

Thomas said:
Garrett said:
Thomas said:
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.
Feature tests for what?

Callability, to the extent this can be detected. The method `method' here
is supposed to add only *methods* after all.
No *what*?

No, it is not unnecessary.
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.
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.
Possible, but that does not preclude abstractions from being not misleading
in general.


Impossible to say without seeing the called code. In any case, your proof-
by-example is fallacious.


No, it is within the aggregation that comes with this "namespacing" which
forces more evaluation. Local aliasing cannot prevent that, only alleviate
it.


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.
 
T

Thomas 'PointedEars' Lahn

David said:
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.
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.
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.
I miss no such thing. In the context we are discussing (ActiveX
object instantiation), it does not apply.

Why the inappropriate example then?
Happens.


Too late for the script in question to go on about its merry way.

Is there any proof for your assumption?
"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.
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.
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, it isn't working.

Unfortunately.


PointedEars
 
D

David Mark

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. :)
No, that *is* the point.

*Sigh* See above.
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.



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?
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?
Non sequitur.

I really dislike this sort of endless arguing about nothing.
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.
Yes.



Is there any proof for your assumption?

Proof that uncaught exceptions derail executions without recourse?
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.
Your probability argument is fallacious.

I don't think so.
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.



Unfortunately.

Can we agree to stop trying to clarify whatever it is you think needs
clarifying then?
 
T

Thomas 'PointedEars' Lahn

Garrett said:
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.
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


No, I don't miss your point. I got it.

Your statement indicated otherwise. Then again, I have no idea what
"calling `namespace'" exactly means in your book.
You wrote that foo.bar.baz is less efficient that just `foo`. You're
right; it is. But that is hardly a consideration because the efficiency
of lookup for user-defined objects is fast.

Non sequitur. "fast" is relative.
(function(){
var foo = { bar : {baz :0 } };
var d = new Date;
for(var i = 0; i < 10000; i++)
foo.bar.baz = foo.bar.baz+1;
return new Date-d;
})();

Ten thousand iterations and it is running in under 10ms.

Your test case is flawed as the function code does not contain any
identifier referring outside of the function.
Performance with DOM operations is a different matter. For DOM ops,
[[Get]] is going to often perform not just a property lookup, but
something else more expensive.

(function(){
var foo = document.body;
var d = new Date;
for(var i = 0; i < 10000; i++)
foo.firstChild.nextSibling
return new Date-d;
})();

Bumps it up to 200ms in IE.

Which is also due to the fact that this time there is an identifier
referring outside of the function, document. My point exactly.
Then there is the issue of evaluating the call to the namespace
function.

But nobody talked of a "namespace function" yet. (Perhaps that is what you
mean by "calling `namespace'"?)
That will happen at load time, not runtime. A heavy
application might use up to 50 calls to create a namespace. That would
not be measurable in milliseconds (maybe 1 millisecond on a 2ghz
machine).

If I bump the number of calls up to 1000, and declare 1000 unique
"packages" off a "base" package, with two sub-packages, there should be
a total of 3001 packages d.b0, d.b0.c, d.b0.c.d, d.b1...

(function(){
var APE= window.APE;

I do hope you are not augmenting host objects.
var d = new Date;
for(var i = 0; i < 1000; i++)
APE.namespace("d" + ".b" + i + ".c.d");

What exactly does it do? (No, I am not going to dig through your code.)
return new Date-d;
})();

[...]

All this is very interesting, but it evades the issue.
Access property off global object:

You have been told before that `window' is _not_ an appropriate means to
refer to the global object.
(function(){
var p = window;
var d = new Date;
for(var i = 0; i < 10000; i++)
p["d" + ".b" + i + ".c.d"] = i;

So you are augmenting host objects after all?


PointedEars
 
T

Thomas 'PointedEars' Lahn

David said:
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.
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.
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").
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.
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.
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.
Proof that uncaught exceptions derail executions without recourse?

Yes (IIUC).
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.
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.
Well?


Can we agree to stop trying to clarify whatever it is you think needs
clarifying then?

I am afraid we cannot.


PointedEars
 
J

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 ?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top