typeof for feature testing host methods

[David Mark]

2nd, "David's concern",a is not answered yet because it is not clear
what this concern is about: what is "missing [[Get]] for ActiveX
objects"

Let me see if I can explain it in terms you will understand.

Your browser is drunken cowboy that shoots parrots and squids in
fields of red and blue flowers and vice versa.

OK... If the "Thomas' concern" may be possibly solved by
programmatical means then "David's concern" seems out the knowledge
of c.l.j. He really concerns me now... not his concern...

Sorry, I didn't have an English to VK dictionary handy. To avoid
future confusion, perhaps you should create and post in a new group:
comp.lang.javascript.vk. If you don't know how to do this, I'm sure
somebody here will volunteer to help.

 

[Peter Michaux]

I've
also changed it to check "unknown" objects for null. It seems to me an
"unknown" object that is null would be somewhat useless.
var reFeaturedMethod = new RegExp('^function|object|unknown$', 'i');
var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if o doesn't have [[Get]]
return !!(reFeaturedMethod.test(t) && o[m]);
}
catch(e) {
return false;
}
};
Laps in judgment above. Should be
var reFeaturedMethod = new RegExp('^function|object$', 'i');
var isFeaturedMethod = function(o, m) {
try {
var t = typeof(o[m]); // throws error if
This does not throw an error. Example:
(typeof window.external.addFavorite)

In the ECMAScript standarad the above expression uses [[Get]].

Evaluates to "unknown"
(window.external.addFavorite)
Throws an error in IE.

In the ECMAScript standard the above expression uses [[Get]] just like
the typeof expression above.

I didn't think it did. I'll take your word for it.

I was hoping no one would take my word for it!

In "typeof UnaryExpression" and "if (Expression) Statement" both the
UnaryExpression and the Expression are evaluated first. GetValue is
called on the result of this evaluation. GetValue calls [[Get]].

It could be something more along the lines of the ToBoolean that is
the problem here instead of a missing [[Get]].

Whether it is a missing [[Get]] or one that deliberately throws errors
is unclear to me.

I don't think we can every know. It is important to keep in mind that
even a compliant browser doesn't need to have an internal [[Get]] but
must behave as though it does. That means if it is implemented one way
for "typeof" and another way for "if" and there is a bug in one of the
implementations then the behavior will not be as though there is an
internal [[Get]].

[[Get]] and ToBoolean are only included in the standard as ways to
explain the actual standard.

So I don't see what benefit the try clause adds.

In a practical sense perhaps nothing. There is nothing in the standard
that states typeof would catch an error thrown if [[Get]] is missing.

This surprises me as typeof(anUndeclaredIdentifier) doesn't throw an
error. But then, I suppose it skips the [[Get]] in that case and just
returns undefined. I'll have to go back and re-read that section.

Evaluation of "anUndeclaredIdentifier" only involves [[HasProperty]]
and when the identifier is undeclared will return a Reference with
Base "null". When the typeof evaluates a reference with Base "null" it
returns "undefined". So according to the standard this should not
throw an error.

From what you have mentioned here (and in the previous post that I
didn't read thoroughly enough), it is no guarantee. It is simply the
best practical solution.


So noted.




I guess we need two implementations of that function with appropriate
warnings.

I think the try-catch implementation should be there but I probably
won't bother using it. Not to support old browsers but there must be
some runtime overhead of try-catch. If there comes a day when typeof
does start throwing an error it will be easy to switch
implementations. I think this sort of depth of investigation reflected
in the documentation is what will make the code truly worth
recommending.

 

[Peter Michaux]

Peter Michaux said the following on 12/15/2007 12:04 AM:

There have been many threads lately about testing for the existence of
host object methods. I have usually just feature tested the existence
of host methods with the following

if (document.getElementById)

var newScript = document.createElement('script');
newScript.type = "text/javascript";
var s = document.createTextNode(d[x].text);
newScript.appendChild(s);

Ever seen that code? (Or rather, something close to it). You can feature
test your head off

Sometimes I think that when designing a feature test we are just lucky
to find a particular path of feature testing that works. If there were
more browsers with more weird bugs, there may be no path of feature
testing that worked. It may be the only way would be
navigator.userAgent or some other method to determine the browser
rather than test it's features.

and IE will pass every one of them. It still falls
down on itself when trying to appendChild to a script element. The only
way to know it is going to work, or not, in IE is to execute it or
detect IE - either through explicit or implicit tests.


I think it is, in some cases, but for different reasons.


And if it is over-written, then isn't the author better off knowing that
he screwed up rather than trying to get around that?

Yes. If host objects are being overwritten the code is basically
screwed and anything could happen. If somewhere before my code feature
tests for document.getElementById someone has written the following
then I have a detailed feature test to write that is way to paranoid
to consider writing.

document.getElementById = function() {
throw new Error('heheheheeh, gotcha!');
}

Let's say it is in
a library that a native function is over-written.

<script src="libraryX.js"></script>
<script src="libraryY.js"></script>
<script src="libraryZ.js"></script>

If libraryX over-writes it, then the page author needs to know, as soon
as possible, that the author of libraryX was smoking weed when he did
it.



Trying to compensate for that in libraryY or libraryZ isn't solving
a problem, only making it transparent so that the real problem doesn't
get corrected. Don't confuse that with trying to correct bugs in a
browser (e.g. IE and toFixed).


Remember that you are referring to a person who wrote a 306 line script
to do a simple image swap.

If he can convince his boss that is a good use of time then good for
him.

That is part of the problem in this group. People trying to make things
more difficult than they have to be simply because some browser back in
1997/1998 won't execute the present day code.

I also think that trying to detect that failure will mask potential bugs
in browsers.

Another reason for concern is that even though the host may provide a
callable document.getElementById but that when writing just "if
(document.getElementById)" it isn't the [[Call]] property the [[Get]]
property that is used. David Mark seems to think this is a problem
with some (all?) ActiveX objects. All host objects are required to
implement [[Get]] so IE is not ECMAScript compliant if it does not. So
when we are feature testing host objects we are worried about testing
ECMAScript non-compliant browsers.

ActiveX components are different animals and need to be dealt with
differently.

If ActiveX objects are exposed in a compliant ECMAScript
implementation then they are host objects. Host objects must have
[[Get]]

As for ECMAScript, we will leave that one alone.



That is why I have always said "Give me what works, not what some
standard says". You can write 100% "compliant" code and if it won't
execute properly in a browser then it is pretty useless, isn't it?

Of course it is and I agree with you.

Suppose there are two ways to write code and they both work in all the
browsers. In addition to this one of them is standards compliant. I
would choose the standards compliant one because the other one
probably only works due to luck or browser bugs. Choosing the
standards compliant way makes sense because hopefully implementations
are moving towards the standard and removing bugs. This is why I was
looking into the standards.

 

[David Mark]

David Mark said the following on 12/15/2007 3:52 PM:

Peter Michaux said the following on 12/15/2007 12:04 AM:
There have been many threads lately about testing for the existence of
host object methods. I have usually just feature tested the existence
of host methods with the following
if (document.getElementById)
var newScript = document.createElement('script');
newScript.type = "text/javascript";
var s = document.createTextNode(d[x].text);
newScript.appendChild(s);
Ever seen that code? (Or rather, something close to it). You can feature

Many times.

Then you know the problems with trying to feature test for it.
Yes.

I use the canHaveChildren property.

That is implicitly testing, not directly testing though. My point is
simply that no *direct* testing of the properties that are used will
uncover the failure. And, nobody can say if that is the only one or if
there are more. Or, even if there are some places in other browsers with
the same type of problems.

I think it is a very appropriate test for IE. That is what that
property is for.

<URL:http://pointedears.de/scripts/test/dom/hoverMe/>

The hoverMe-3.0.js file is 306 lines long. To do an image swap.

I'll skip that one.

Not sure what nee means. But, I searched for isHostMethod and
isFeaturedMethod and it is buried in a 150+ post thread. I didn't keep
up with that thread so not sure exactly what you think the two lines
would be.

The original two lines haven't changed. Take a look at the Code Worth
Recommending project if you want a clearer view of the code discussed
so far (and a lot of proposed code that hasn't yet been discussed.)

Anybody can break anything if they set out to do it. But, what is the
point in writing a "two line function" that can be trivially defeated?

The point is that it is far better than feature testing like this:

if (document.getElementById) {
....
}

The main enhancements are that it doesn't blow up on ActiveX objects,
isn't fooled by overwriting host methods with true, 1, etc. and allows
for simplified gateway code with centralized testing logic. Writing
similar code over and over would bloat applications and make for
future maintenance headaches (assuming a browser comes out in the
future and breaks something in an unforeseen way.)

 

[VK]

Sorry, I didn't have an English to VK dictionary handy. To avoid
future confusion, perhaps you should create and post in a new group:
comp.lang.javascript.vk. If you don't know how to do this, I'm sure
somebody here will volunteer to help.

If someone does know Javascript well enough then she doesn't need to
run for sorry excuses of the type. Who does not - then of course she
needs the sorry excuses. A sample is just a bit above.

To break the impression you have produced so far you still may try to
explain what "missing [[Get]] for ActiveX objects" is. You don't have
to use English at all for that: just a snippet of code with //!?
comment right-hand side of the weak - by your opinion - code.

It is a Usenet group, not a development team billboard, so any code or
argumentation outside of the current thread should be linked or
quoted. No one has to read all posts of yours for the last X days in
all threads just to be able to understand what are talking about.

 

[David Mark]

quoted. No one has to read all posts of yours for the last X days in
all threads just to be able to understand what are talking about.

All you have to do is read this thread, which should be a prerequisite
to posting in any thread.

 

[Thomas 'PointedEars' Lahn]

[...] Thomas Lahn seems particularly concerned about these problems (and
he is preparing to tell I am wrong or that I have missed the point.)

Yes, I am. *eg*

Another reason for concern is that even though the host may provide a
callable document.getElementById but that when writing just "if
(document.getElementById)" it isn't the [[Call]] property the [[Get]]
property that is used. David Mark seems to think this is a problem with
some (all?) ActiveX objects. All host objects are required to implement
[[Get]] so IE is not ECMAScript compliant if it does not.

You miss the point. (See? ;-)) Host objects need to implement [[Get]],
but they do not need to implement it in the way that is defined in the
ECMAScript Specification. IOW, they may throw an exception as well.

| 8.6.2 Internal Properties and Methods
|
| [...]
| Every object (including host objects) must implement the [[Prototype]]
| and [[Class]] properties and the [[Get]], [[Put]], [[CanPut]],
| [[HasProperty]], [[Delete]], and [[DefaultValue]] methods. [...]
|
| [...]
| For native objects the [[Get]], [[Put]], [[CanPut]], [[HasProperty]],
| [[Delete]] and [[DefaultValue]] methods behave as described in described
| in sections 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.6.2.4, 8.6.2.5 and 8.6.2.6,
| respectively, except that Array objects have a slightly different
| implementation of the [[Put]] method (section 15.4.5.1). Host objects may
^^^^^^^^^^^^^^^^
| implement these methods in any manner unless specified otherwise; for
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| example, one possibility is that [[Get]] and [[Put]] for a particular host
| object indeed fetch and store property values but [[HasProperty]] always
| generates false.
|
| In the following algorithm descriptions, assume O is a native ECMAScript
^^^^^^^^^^^^^^^^^^^^^^^^
| object and P is a string.
^^^^^^
|
| 8.6.2.1 [[Get]] (P)
| [...]

So when we are feature testing host objects we are worried about testing
ECMAScript non-compliant browsers.

Quite the opposite.

[...] Both

if (document.getElementById)

and

typeof document.getElementById

are described as calling [[Get]] somewhere in their evaluation.

It is important where that "somewhere" is:

| 8.7.1 GetValue (V)
|
| 1. If Type(V) is not Reference, return V.
| 2. Call GetBase(V).
| 3. If Result(2) is null, throw a ReferenceError exception.
| 4. Call the [[Get]] method of Result(2), passing GetPropertyName(V)
| for the property name.
| 5. Return Result(4).
|
| [...]
| 11.4.3 The typeof Operator
|
| The production UnaryExpression : typeof UnaryExpression is evaluated as
| follows:
|
| 1. Evaluate UnaryExpression.
| 2. If Type(Result(1)) is not Reference, go to step 4.
| 3. If GetBase(Result(1)) is null, return "undefined".
| 4. Call GetValue(Result(1)).
| 5. Return a string determined by Type(Result(4)) according to the
| following table:
| [...]

If a browser really did not supply the [[Get]] property at all for
an object then both likely throw an error and probably a TypeError.

Non sequitur.


HTH

PointedEars

 

[VK]

All you have to do is read this thread, which should be a
prerequisite to posting in any thread.

I was talking only about "Thomas' concern" so far. As by "David's
concern" I see only one so far:
http://groups.google.com/group/comp.lang.javascript/msg/caaacf270455e2c0

btw the method name is "AddFavorite" not "addFavorite":
http://msdn2.microsoft.com/en-us/library/ms535926.aspx

but the method name is of a VB written ActiveX object so case-
insensitive. One may use it even as window.external.addfaVorite(URL)
with no problem. That alone properly suggests what you are behind any
jurisdiction of Javascript.
And again coming back to the first, "Thomas' concern", even if a
workaround found, how does it protect from say:

window.external = {
'AddFavorite' : function() {
return true;
}
}

You should really re-spell the task you are trying to achieve. Do you
want some xtypeof guarantees to say true or false on "is callable"
request and these true and false are always right? You cannot do that
for 100% of situations, even if you spend the rest of your lives on
programming typeof wrappers. Do you agree on some lesser universal
compromise? If yes then what would it be?

 

[Peter Michaux]

[...] Thomas Lahn seems particularly concerned about these problems (and
he is preparing to tell I am wrong or that I have missed the point.)

Yes, I am. *eg*

Another reason for concern is that even though the host may provide a
callable document.getElementById but that when writing just "if
(document.getElementById)" it isn't the [[Call]] property the [[Get]]
property that is used. David Mark seems to think this is a problem with
some (all?) ActiveX objects. All host objects are required to implement
[[Get]] so IE is not ECMAScript compliant if it does not.

You miss the point. (See? ;-)) Host objects need to implement [[Get]],

They don't. They need to behave as though the implement [[Get]]. See
section 8.6.3 in ES3. That is the point. If two parts of the spec
require [[Get]] then in an implementation they may not necessarily be
calling the same little bit of internal code to achieve the behavior
of [[Get]]. For example, the algorithm may be inlined in one place for
optimization. A bug in one of these bits of code that adds the [[Get]]
behavior may result in the behavior we are discussiong where "if
(document.getElementById)" could error but "typeof
document.getElementById" may not error

but they do not need to implement it in the way that is defined in the
ECMAScript Specification. IOW, they may throw an exception as well.

True. This suggests wrapping the feature testing in try-catch is a
good idea, if the desired behavior is to avoid thrown errors being
visible to the user.


[snip]

 

[Thomas 'PointedEars' Lahn]

[...] Thomas Lahn seems particularly concerned about these problems (and
he is preparing to tell I am wrong or that I have missed the point.)

Yes, I am. *eg*

Another reason for concern is that even though the host may provide a
callable document.getElementById but that when writing just "if
(document.getElementById)" it isn't the [[Call]] property the [[Get]]
property that is used. David Mark seems to think this is a problem with
some (all?) ActiveX objects. All host objects are required to implement
[[Get]] so IE is not ECMAScript compliant if it does not.

You miss the point. (See? ;-)) Host objects need to implement [[Get]],

They don't.

Yes, they do. That is explicitly stated by the Specification, as I pointed
out in the part that you snipped.

They need to behave as though the implement [[Get]].

That is a matter of interpretation. Do host objects implement [[Get]] if
their [[Get]] implementation differs from what is specified in the [[Get]]
subsection of ECMAScript, as it is explicitly allowed by ECMAScript for its
conforming implementations? I say yes.

True. This suggests wrapping the feature testing in try-catch is a
good idea, if the desired behavior is to avoid thrown errors being
visible to the user.

Hardly. try..catch may throw its own errors for the UAs where
feature-testing would prevent all errors there otherwise.


PointedEars

 

[Thomas 'PointedEars' Lahn]

You miss the point. (See? ;-)) Host objects need to implement [[Get]],

They don't. They need to behave as though the implement [[Get]]. See
section 8.6.3 in ES3. [...]

There is no such section in the final revision of ECMA-262 Edition 3.


PointedEars

 

[David Mark]

I was talking only about "Thomas' concern" so far. As by "David's
concern" I see only one so far:http://groups.google.com/group/comp.lang.javascript/msg/caaacf270455e2c0

btw the method name is "AddFavorite" not "addFavorite":http://msdn2.microsoft.com/en-us/library/ms535926.aspx

Actually, it is either. Though I typically use addFavorite.

but the method name is of a VB written ActiveX object so case-
insensitive. One may use it even as window.external.addfaVorite(URL)

Thank you.

with no problem. That alone properly suggests what you are behind any
jurisdiction of Javascript.

Whatever that means.

And again coming back to the first, "Thomas' concern", even if a
workaround found, how does it protect from say:

window.external = {
'AddFavorite' : function() {
return true;
}

}

You don't. Case closed on that.

You should really re-spell the task you are trying to achieve. Do you

No I shouldn't.

want some xtypeof guarantees to say true or false on "is callable"
request and these true and false are always right? You cannot do that
for 100% of situations, even if you spend the rest of your lives on
programming typeof wrappers. Do you agree on some lesser universal
compromise? If yes then what would it be?

How can you possibly not understand what the two-line function does
and does not do at this point. It boggles the mind.

 

[Peter Michaux]

Peter Michaux wrote:
[...] Thomas Lahn seems particularly concerned about these problems (and
he is preparing to tell I am wrong or that I have missed the point.)
Yes, I am. *eg*
Another reason for concern is that even though the host may provide a
callable document.getElementById but that when writing just "if
(document.getElementById)" it isn't the [[Call]] property the [[Get]]
property that is used. David Mark seems to think this is a problem with
some (all?) ActiveX objects. All host objects are required to implement
[[Get]] so IE is not ECMAScript compliant if it does not.
You miss the point. (See? ;-)) Host objects need to implement [[Get]],

They don't.

Yes, they do. That is explicitly stated by the Specification, as I pointed
out in the part that you snipped.

Read the first paragraph of 8.6.2. The internal properties are not
part of the language and are not required. What is required is the
implementation behaves as though the internal properties are used.

They need to behave as though the implement [[Get]].

That is a matter of interpretation.

No. Read the third sentence of 8.6.2.

Do host objects implement [[Get]] if
their [[Get]] implementation differs from what is specified in the [[Get]]
subsection of ECMAScript, as it is explicitly allowed by ECMAScript for its
conforming implementations?

The specification is particularly weak in this area.

I say yes.

That is what the second to last sentence of 8.6.2 says. It does seem
to contradict the first paragraph of 8.6.2.

Hardly. try..catch may throw its own errors for the UAs where
feature-testing would prevent all errors there otherwise.

try-catch may throw syntax errors in non-compliant browsers and in a
practical sense all old browsers. Internal properties would throw
runtime errors which would be more frequent (every user interaction)
and this could occur in compliant and current/future browsers.

There is no magic bullet.

 

[David Mark]

[...] Thomas Lahn seems particularly concerned about these problems (and
he is preparing to tell I am wrong or that I have missed the point.)

Yes, I am. *eg*

Another reason for concern is that even though the host may provide a
callable document.getElementById but that when writing just "if
(document.getElementById)" it isn't the [[Call]] property the [[Get]]
property that is used. David Mark seems to think this is a problem with
some (all?) ActiveX objects. All host objects are required to implement
[[Get]] so IE is not ECMAScript compliant if it does not.

You miss the point. (See? ;-)) Host objects need to implement [[Get]],

They don't. They need to behave as though the implement [[Get]]. See
section 8.6.3 in ES3. That is the point. If two parts of the spec
require [[Get]] then in an implementation they may not necessarily be
calling the same little bit of internal code to achieve the behavior
of [[Get]]. For example, the algorithm may be inlined in one place for
optimization. A bug in one of these bits of code that adds the [[Get]]
behavior may result in the behavior we are discussiong where "if
(document.getElementById)" could error but "typeof
document.getElementById" may not error

but they do not need to implement it in the way that is defined in the
ECMAScript Specification. IOW, they may throw an exception as well.

True. This suggests wrapping the feature testing in try-catch is a
good idea, if the desired behavior is to avoid thrown errors being
visible to the user.

I disagree with that for most cases. This is only useful for
applications and enhancements that are known to be 100% incompatible
with browsers that cannot parse try-catch. In any event, script
errors are not the most graceful way to degrade.

As there are no known agents that throw script errors in the
isHostMethod or isRealObjectProperty functions, it would seem that
adding a try-catch protects against potential problems with future
agents, but at the cost of throwing real errors in older ones.

Doesn't really matter though as we can just have two versions in the
repository. It should be noted in the documentation when a specific
implementation features a try-catch clause. AFAIK, there is only the
Ajax wrapper and one implementation of urlencode so far.

 

[VK]

You don't. Case closed on that.

Closed by who? Please do not mix a ticket case on a support desk with
a Usenet thread. Anyone can start one. No one rule it, though OP
author's asks are usually getting more attention then others. If you
cannot agree with that then you should work on a moderated project
site instead.

No I shouldn't.

Yes you should: again, if you are planning to work in the Usenet. Up
till now in the the thread I see only Peter's formulation of your
concerns in his OP. From your side I see nothing but two isolated
lines of code at
http://groups.google.com/group/comp.lang.javascript/msg/caaacf270455e2c0
- minus "drunk cowboys", "flowers" etc.
If you have anything to discuss with the community then do it. If
everything is clear to yourself and all cases are closed then why are
you keep posting at c.l.j. ?

How can you possibly not understand what the two-line function does
and does not do at this point. It boggles the mind.

Again, two lines in where? in Peter's code? Which ones? Your own code
- I mean posted from your name - I have found in this thread consists
of

This does not throw an error. Example:

(typeof window.external.addFavorite)

Evaluates to "unknown"

(window.external.addFavorite)

Throws an error in IE.

Are these "two lines of code" you are talking about? Something else?
Can you stop pretending to be Mr. Very Mysterious Man for a second?

For the error on window.external.addFavorite then of couse it throws
exception. Who the hey would decide to try to apply JavaScript type
conversion rules on a VB chunk of code? That one of rules of higher
level programming: do not relay on boolean type conversions. They are
great for quick-n'-dirty coding and I use them a lot. But to play on
the safe side the rule changes: "you need a boolean check - so use
boolean values".

if (('external' in window) &&
('AddFavorite' in window.external)) {
// keep wasting your time
// until spuffed
}
else {
// you are lucky or
// finally spuffed so
// start to do something
// useful
}

 

[Thomas 'PointedEars' Lahn]

[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
[...] Thomas Lahn seems particularly concerned about these
problems (and he is preparing to tell I am wrong or that I have
missed the point.)
Yes, I am. *eg*
Another reason for concern is that even though the host may
provide a callable document.getElementById but that when writing
just "if (document.getElementById)" it isn't the [[Call]]
property the [[Get]] property that is used. David Mark seems to
think this is a problem with some (all?) ActiveX objects. All
host objects are required to implement [[Get]] so IE is not
ECMAScript compliant if it does not.
You miss the point. (See? ;-)) Host objects need to implement
[[Get]],
They don't.

Yes, they do. That is explicitly stated by the Specification, as I
pointed out in the part that you snipped.

Read the first paragraph of 8.6.2. The internal properties are not part
of the language

True:

| 8.6.2 Internal Properties and Methods
|
| Internal properties and methods are not part of the language. They are
| defined by this specification purely for expository purposes. An
| implementation of ECMAScript must behave as if it produced and operated
| upon internal properties in the manner described here.

However, ...

and are not required.

.... that, in its absolute, is wrong.

What is required is the implementation behaves as though the internal
properties are used.

You misunderstand. By the Specification's stating that they are "not part
of the language" it is meant that they are not available for code written
in/for implementations. You won't be able to call O[[Get]](), for example.

Therefore, the Specification says below that:

| Every object (including host objects) must implement the [[Prototype]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| and [[Class]] properties and the [[Get]], [[Put]], [[CanPut]],
| [[HasProperty]], [[Delete]], and [[DefaultValue]] methods.
|
| [...] Host objects may implement these methods in any manner unless
^^^ ^^^^^^^^^^^^^
| specified otherwise; [...]

The bottom line is: Host objects may implement these methods in any manner.
But they *do* need to implement them.

They need to behave as though the implement [[Get]].

That is a matter of interpretation.

No. Read the third sentence of 8.6.2.

Read 8.6.2 yourself, again. And this time you should read the most recent
revision.

Do host objects implement [[Get]] if their [[Get]] implementation
differs from what is specified in the [[Get]] subsection of ECMAScript,
as it is explicitly allowed by ECMAScript for its conforming
implementations?

The specification is particularly weak in this area.

Because your ability of misunderstanding it?

That is what the second to last sentence of 8.6.2 says. It does seem to
contradict the first paragraph of 8.6.2.

But it does not.

try-catch may throw syntax errors in non-compliant browsers and in a
practical sense all old browsers.

Maybe you should stop constraining the use of ECMAScript applications to
browsers. However, it will break in any UA that has a script engine that
does not implement try..catch. Whether that UA is "old" is irrelevant.
Exception handling was among the newest language features that were
implemented. It can not be expected to be supported.

Internal properties would throw runtime errors which would be more
frequent (every user interaction) and this could occur in compliant
and current/future browsers.

Sorry, you miss the point.

There is no magic bullet.

I never said there were. But wrapping feature tests in try...catch blocks
(currently) works (because of its error-proneness) against the purpose and
intention of feature-testing, not in favor of it.


PointedEars

 

[Richard Cornford]

Such a document would imply a relationship that was consistent over
time,. That does not seem a realistic expectation.

If someone does know Javascript well enough then she
doesn't need to run for sorry excuses of the type. Who
does not - then of course she needs the sorry excuses. A
sample is just a bit above.

A reasonable test of whether someone knows what they are talking about
is to ask them what they mean and see if they answer (at all, or
meaningfully). In this thread you have been asked to explain what you
mean and you have refused to do so. Anyone who did not already know you
might then reasonably conclude that you do not know what you are talking
about. The rest of already know that your incoherent gibbering is a
direct reflection on your mental processes and so can see that there is
no clearer explanation to be given.

To break the impression you have produced so far you
still may try to explain what "missing [[Get]] for
ActiveX objects" is.

No explanation is necessary. It is an explanation for the fact that
value retrieval operations throw exceptions. That the absence of an
internal [[Get]] method is not the only explanation, and not necessarily
the best explanation, has already been discussed.

You don't have to use English at all for that: just a snippet
of code with //!? comment right-hand side of the weak - by
your opinion - code.

That code has been posted in this thread, followed by the assertion that
it would throw an exception in IE. You inability to recognise that does
not mean it has not happend.

It is a Usenet group, not a development team billboard,
so any code or argumentation outside of the current thread
should be linked or quoted.

You want links? Yes, lets have some links. Lets start with seeing how
good a programmer the person who started a post in this thread with the
words "A really good program/programmer must ... " actually is:-

Do you remember your 'Vector' effort:-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/2820fbcd4b4ab7f8- the one that received the accolade "It uses the most bizarre and
obtuse storage method I've ever witnessed, and it uses it inconsistently
and without any obvious benefits."

And how, embarrassed by that you tired to show off with another
version:-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/2820fbcd4b4ab7f8
- that turned out to be more of a data mangling object than a data
storage object, and took someone else's efforts to fix. An example that
speaks to not only to the depth of your understanding of the code you
write but also to your abilities in the area of testing your own code as
you posted unaware of how totally flawed it was.

There was that 'rounding' function that did not even manage to output
its resutls with the correct number of decimal places in some cases (let
alone get the decimal digits in that output even close to anyone's
expected results):-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/2f869add6d8dfcad
- That was the own that you were still declaring the 'superiority' of
after its faults had started to be pointed out.

Then there was your test code to see if an object was an Array or not,
about which you said "This code as absolutely robust (there is no way to
cheat on it)":-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/a2c2f69c6d9004ba
- regardless of the facts that it both could be 'cheated' (using
standard ECMA 262 3rd Ed. code) and that it modified the length every
Array that was tested with it).

This Array test also highlights your grasp of javascript as a langue,
when you demonstrated your misconception of how the - delete - operator
works (and you claim to have nearly 10 years 'experience' with the
language):-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/a2c2f69c6d9004ba
But that misconception was no suppose given your record, and assertions
like "the entire method call must be one line":-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/90f1379769c5a2ec
- and code like:-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/5ad2b7796f36339b
- along with so very much else over the years.

Eventually we come to browser scripting, and your ability to understand
the browser environment (and so your analytical abilities in general),
and so to this:-

<URL:
http://groups.google.com/group/comp.lang.javascript/msg/b6e5bfd65e6813af
- for example, or my personal favourite where you used the words "as
usual 2 months of experiments are defited by one specs reading..." to
criticise someone for suggesting that Mozilla/Firefox/Gecko browsers
supported the - document.styleSheets - object:-

<URL:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/d9618e13b38a7605/ >

- which, of course, they do, and have done for a very considerable time.
Meaning that the analysis employed in your "2 months of experiments" had
been so fundamentally faulty as to leave you knowing less at the end of
the process than you had at the beginning.

We end up with the question; how can anyone sane be so very obviously
bad a programming, logic and analysis, be presented with so much
evidence of that, and still think of themselves as being in a position
to give advice on what "A really good program/programmer must" do?

Personally I stick to my long standing conclusion that the explanation
is mental illness on your part. That fully explains the incoherent
gibbering, the inability to understand logic, programming languages, and
to program, the inability to analyse effectively and the
inability/unwillingness to recognise any of these faults in yourself.

My conclusion was re-enforced by observing your last post preceding your
recent 'sabbatical' with the subject "Sanskrit jan and English birth":-

<URL:
http://groups.google.com/group/rec.skydiving/browse_frm/thread/c8fe1f47428e4f3a >

- which is gibberish beyond any doubt. It is such gibberish that it
could only be the work of a madman or be machine generated text, but
even if machine generated it would take a loony to post it to Usenet.
And you apparently thought it on topic in alt.skydiving.

I assume they locked you up for a few months shortly after that. You may
be out now but remember they let you out when you are no longer judged
to represent a physical danger to yourself or others; it does not mean
you are cured. Mental illnesses don't tend to get cured, only managed
(or not).

No one has to read all posts of yours for the last X days
in all threads just to be able to understand what are
talking about.

And nobody has to read more than a sample of your posts to see that even
you don't know what you are talking about, let alone anyone else.

Richard.

 

[David Mark]

Closed by who? Please do not mix a ticket case on a support desk with

Case closed by logic. There is no need to argue about something that
has been stipulated.

a Usenet thread. Anyone can start one. No one rule it, though OP
author's asks are usually getting more attention then others. If you
cannot agree with that then you should work on a moderated project
site instead.
Idiot.


Yes you should: again, if you are planning to work in the Usenet. Up
till now in the the thread I see only Peter's formulation of your
concerns in his OP. From your side I see nothing but two isolated
lines of code athttp://groups.google.com/group/comp.lang.javascript/msg/caaacf270455e2c0
- minus "drunk cowboys", "flowers" etc.
If you have anything to discuss with the community then do it. If
everything is clear to yourself and all cases are closed then why are
you keep posting at c.l.j. ?
Idiot.


Again, two lines in where? in Peter's code? Which ones? Your own code
- I mean posted from your name - I have found in this thread consists
of
Idiot.




Are these "two lines of code" you are talking about? Something else?
Can you stop pretending to be Mr. Very Mysterious Man for a second?

Idiot. Peter posted the two-line function that has now been much-
discussed in this thread. Apparently you haven't been paying
attention at all, but that is nothing new.

For the error on window.external.addFavorite then of couse it throws
exception. Who the hey would decide to try to apply JavaScript type
conversion rules on a VB chunk of code? That one of rules of higher
Idiot.

level programming: do not relay on boolean type conversions. They are
great for quick-n'-dirty coding and I use them a lot. But to play on
the safe side the rule changes: "you need a boolean check - so use
boolean values".

Idiot. You don't know when it is safe and when it is not. If you had
read the thread, you would have known that at this point.

if (('external' in window) &&
('AddFavorite' in window.external)) {

That's the last straw.

// keep wasting your time
// until spuffed}

else {
// you are lucky or
// finally spuffed so
// start to do something
// useful

Go "spuff" yourself (whatever that means.) We are done here.

 

[VK]

On Dec 16, 10:24 pm, "Richard Cornford" <[email protected]>
wrote:

<VK >> null>

Oh... 220mm mortars of 2005th series... A heavily outdated armor but
still spooky noisy.

What can I say for everything: loosers are searching for theoretical
failures cases and fighting with any kind of libraries - winners are
leaving them next week for Javascript-paid 3 days of Tahoe snow. ;-)

P.S. What bugs me on the background is that with all human/hours put
so far into document.getElementById detection and other useless doings
one could write a robust wrapper for WebServices (Gecko/IE) or
something else what no one else provide so to be grabbed hot right
from one's hands. It is not my damn business of course what other
people are doing at their spare time, just bugs me a bit.

P.P.S. IMHO and based on my business experience the time for basic
libraries of Prototype.js is gone. It should be maid 3-4 years ago
then everyone was starving around. Now the niche is taken and any -
even the most ugly - older library has a huge advantage over any new
one: just because it already failed X times in different real
situations and was fixed for them. And any new "perfect" library still
has its necessary X failures to happen in the future at someone
expenses. So the only way to grab an attention would be doing some
cutting edge stuff better, quicker and cheaper than anyone else - and
inside such library then one may implement any own ideas of the
correct coding.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

It makes that function next to useless based on that criteria.

Please eschew words that you do not understand; it confuses those who
have undertaken EFL.