Augmenting Types

[David Mark]

Thomas 'PointedEars' Lahn wrote:

[...]

One should if an argument like yours is based on it.

My argument is not based on it at all. Why you can't see that is beyond
me. It's like you've got some wires crossed and I can't find the
short-circuit. I'm tired of trying.

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.

No, *you* do not care about it, for sure.

Why would I? Kangax could shed light on it, but who cares?

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.

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

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.

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.

Yes (IIUC).

That's like asking to prove that 1 + 1 = 2. What's the 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.

You do not know anything of the other code, so you are not in a position to
assess the probability of failure.
Whatever.


Well?

Well what? You snipped whatever it was I was talking about.

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]

David Mark wrote:

[Quotation restored]

My argument is not based on it at all.

OK, let's assume that for brevity. Hopefully that finally leads somewhere.

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

Why would I? Kangax could shed light on it, but who cares?

I wish he would because I do care.

I'm using a newsreader now.

That's good to hear.

I can plonk you for real. Fair warning.



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

This is going nowhere.

Unfortunately. Why would you not at least point me to the "other scripts"?
:-(

[Quotation restored]

Well what? You snipped whatever it was I was talking about.

No, I am afraid you did that. Anyhow, where exactly are these facts that
you provided and that I have snipped? So far I can see only more
assumptions (like "execution has dropped dead at that point").


PointedEars

 

[Jorge]

OMG. What are you saying ?

I mean, the code snippets that you've posted are comparing access time
to an identifier at the end of the scope chain (a global) versus an
identifier in the first link (a local var). That has nothing to do
with whether the object is or isn't "user defined".

 

[Garrett Smith]

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?

 

[Garrett Smith]

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

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;
| }())

 

[Thomas 'PointedEars' Lahn]

Accessing properties off the global object is slower than accessing
properties off a user defined object.

What is confusing about that?

The statement is gibberish and, iff interpreted in your favor, wrong to
begin with. What matters is _not_ whether the object is the global object
or a user-defined object, but in which execution context the property is
defined that refers to the object, and in which execution context the
property name is used (i.e. the length of the effective scope chain), and
how many property accesses (following the scope chain resolution) are
necessary in order to get at the property value that is the reference to
the object.

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.

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.


HTH

PointedEars

 

[John G Harris]

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.[/QUOTE]

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

 

[Garrett Smith]

The statement is gibberish

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]

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

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;
| }())

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 ?

 

[Thomas 'PointedEars' Lahn]

Garrett Smith replied to a cancelled and deleted posting.

 

[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,

 

[Garrett Smith]

(...)
Accessing properties off the global object is slower than accessing
properties off a user defined object.
Access property off global object:
(...)
Access property off user-defined object:
(...)
OMG. What are you saying ?
I mean, the code snippets that you've posted are comparing access time
to an identifier at the end of the scope chain (a global) versus an
identifier in the first link (a local var). That has nothing to do
with whether the object is or isn't "user defined".

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;
| }())

Ok, Garret, excuse me. I misread the code.

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]

Jorge wrote:
(...)
Accessing properties off the global object is slower than accessing
properties off a user defined object.
Access property off global object:
(...)
Access property off user-defined object:
(...)
OMG. What are you saying ?
I mean, the code snippets that you've posted are comparing access time
to an identifier at the end of the scope chain (a global) versus an
identifier in the first link (a local var). That has nothing to do
with whether the object is or isn't "user defined".
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;
| }())

Ok, Garret, excuse me. I misread the code.

I though so.

The only global identifier is `Date`,

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


PointedEars

 

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

 

[Garrett Smith]

[...]

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.

The performance times resulting from using value from `window` or `
(function(){return this;})();` don't vary.

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

just use:-

var p = (function(){return this;})();

(function(){
var p = (function(){return this;})(); // window.
var d = new Date;
for(var i = 0; i < 10000; i++)
p["d" + ".b" + i + ".c.d"] = i;
return new Date-d;
}())

Make sure to reload the page after running each test. Subsequently
running the test will be faster.

Also, you can type the code into bookmarklet to run in Firefox.

1) copy code above
2) javascript:alert( /*paste*/ )
3) Hit Enter.

Again, the performance times resulting from using value from `window` or
` (function(){return this;})();` don't vary.

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

For property assignment, it should be a [[Put]] on that object. For
window, well, window has an extended prototype chain that includes a
[[GlobalScopePolluter]], and so it may be referencing properties on that.

Larger number of properties on the object might also slow performance.

 

[Garrett Smith]

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

How is this a proof?

`Object' is a built-in function.

What do you think the Object Constructor is? Why do you think the
specification calls it "The Object Constructor"?

 

[Jorge]

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

That's what one would logically deduce, but the tests show that
there's something else (in addition). He is aliasing the target object
in a local var, and even so there's a slight difference in speed: when
the aliased object is either the window object or the global object
access times are longer than when the object is a {}.

http://jorgechamorro.com/cljs/090/

And disabling FireBug does not seem to have an effect on the results.

 

[Garrett Smith]

Could you please elaborate ?

First mobile web browser? Apple? No, how about windows mobile or maybe
Nokia S60.

Which is ... ?

Safari on iPhone, of course. Doesn't support even basic CSS overflow;
Doesn't support mousemove event.

You probably mean the touch/gestures iPhone JS API ?

Yes.


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.

I could care less about Flash. How about not monopolize the OS by
disallowing Fennec, which is free.

And the saying think before you talk means exactly what it says.

Did you have a point or?

 

[Jorge]

First mobile web browser? Apple? No, how about windows mobile or maybe
Nokia S60.

Mobile IE ? Are you serious ? That's the worst IE ever ! even worse
than desktop IE ! (wait, is that possible ?)

And S60 === a badly broken, buggy fork of webkit. Still, much better
than any mobile IE.

The truth is that the first serious, decent browser ever on a
smartphone has been mobile Safari. No matter what you say or how much
you hate Apple and everything Apple. That's not my personal opinion,
it's a fact, it's history.

Safari on iPhone, of course. Doesn't support even basic CSS overflow;

Assuming you mean e.g. overflow-x:hidden; , which version does not
support that ?

Doesn't support mousemove event.

Does not need to as there's no mouse in the iPhone

Yes.

They are in their own right. And they have *not* said a word (yet)
about the licensing fees (if any). It could be licensed for free (and
eventually it could even become an w3 standard, then)
*but*only*if*Apple*wanted*...

I could care less  about Flash. How about not monopolize the OS by
disallowing Fennec, which is free.

Fennec ? What's Fennec ?

Did you have a point or?

Yes, that your comments really make me sick. grrr.

 

[Jorge]

And S60 === a badly broken, buggy fork of webkit.

....that -besides- has not been updated ever since v1.0.