VK wrote:
[Please learn how to quote, see the FAQ. Quotation levels corrected here.]
And to make your evening also take a look at the title of this thread.
Ahh, yes. Quite bold of you to give it v1.0; it's more like v0.1.
If say method X works in 98% of cases and method Y works in 99% of
cases then given all other issues being equal (simplicity, code
readability etc.), then method Y is a better practice.
Which exactly is why "in" is not.
In the "IN vs. UNDEFINED" case I don't see "other issues" equal
neither. They are definitely benifiting to "IN":
^^^^^^^^^^
(May I say that even as a person with English as foreign language myself
I am quite astonished by the overall "style" of your pos(t)ings?)
[1]
if ('someProperty' in someObject) {...}
follows the human language structure so it's easy to understand [...]
You are completely missing the point again. This feature of the operand
identifier was not debated. What was debated and is still debatable was
the extend of the support of the operand as a feature of the programming
language implementation(s).
[2]
if ('someProperty' in someObject) {...}
contains only one operation (hash LOOKUP)
No, if you had bothered to read ECMAScript 3 (as suggested to you
several times before), section 11.8.7., you would have known that
the "in" operation requires 8 steps total. If all subalgorithms
are considered, it takes even more steps:
| The production
|
| RelationalExpression :
| RelationalExpression in ShiftExpression
|
| is evaluated as follows:
|
| 1. Evaluate RelationalExpression.
| RelationalExpression :
| ShiftExpression
| RelationalExpression < ShiftExpression
| RelationalExpression > ShiftExpression
| RelationalExpression <= ShiftExpression
| RelationalExpression >= ShiftExpression
| RelationalExpression instanceof ShiftExpression
| RelationalExpression in ShiftExpression
|
| (I save you the details of that here, read for yourself)
|
| 2. Call GetValue(Result(1)).
| 1. If Type(V) is not Reference, return V.
| 2. Call GetBase(V).
| GetBase(V). Returns the base object component of the reference
| 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.
| GetPropertyName(V). Returns the property name component of the
| reference V.
| 5. Return Result(4).
|
| 3. Evaluate ShiftExpression.
|
| ShiftExpression :
| AdditiveExpression
| ShiftExpression << AdditiveExpression
| ShiftExpression >> AdditiveExpression
| ShiftExpression >>> AdditiveExpression
|
| (again, no more details here)
|
| 4. Call GetValue(Result(3)).
| 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).
|
| 5. If Result(4) is not an object, throw a TypeError exception.
| 6. Call ToString(Result(2)).
See section "9.8 ToString" for details.
|
| 7. Call the [[HasProperty]] method of Result(4) with parameter Result(6).
| 8. Return Result(7)
while
if (someObject.someProperty) {...} has two operations:
1) resolve someObject.someProperty (hash LOOKUP)
2) do background casting to false/true
Actually, it's
| 1. Evaluate MemberExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate Expression.
| 4. Call GetValue(Result(3)).
| 5. Call ToObject(Result(2)).
See section "9.9 ToObject" for details.
| 6. Call ToString(Result(4)).
See section "9.8 ToString" for details.
| 7. Return a value of type Reference whose base object
| is Result(5) and whose property name is Result(6).
and then type-cast the return value to Boolean.
so the same for
if (typeof(someObject) == 'function')
typeof is an operator, not a function. The parentheses are unnecessary.
1) get someObject typeof
2) compare with string
That's actually
| 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: [see "11.4.3 The typeof Operator" for more]
and then compare the return value with the string value.
On double check
if ('someProperty1' in someObject) && ('someProperty2' in
someProperty1) {...}
we save on two unnecessary operation avoided.
See above. What looks simple in the source code is not at all simple
or efficient in the implementation. This could be considered rule of
thumb since complexity does not simply vanish because of convenience.
BTW: You do know that the former throws a TypeError exception if
`someObject' does not refer to an object, too?
Do not get redicilous now. ^^^^^^^^^^
What?
You mean that 99's ECMA lacks wide support?
The specification is called ECMAScript or ECMA-262. ECMA is the
standardization body that publishes it. ECMAScript Edition 3 Final
is dated March 24, 2000.
Most features of ECMAScript 3 are implemented as (and extended by)
JScript 5.6 (IE 6), JavaScript 1.5 (Mozilla/5.0) and by the scripting
engine of newer Opera versions.
As we are talking about cross-platform scripting here then terms like
"some browsers" should be sctrictly avoided in the discussion.
Pardon? "some browsers" and interoperability is the whole point of
cross-platform scripting!
Otherwise it's just a hidden way to say "I simply don't like it/you".
You are talking nonsense again. More important, you are fighting your
own argument. If "I simply don't like you" is not what you want, then
insisting on having a not supported feature to be called best practice
is a step towards the wrong direction by 180°.
There are not "some browsers".
There are.
There is IE 3.x - 7.x, Netscape 2.x - 8.x, Firefox 1.0.x, Pan 0.x and
so on and so on.
Obviously you gave last part not enough thought.
You think that a particular method will fail in some environment?
I *know* that it will fail in some environments just because environments
are different. The probability that "in" will fail is higher than the
probability that "typeof" will fail, just because the former came last.
That's cute of you talking the "we" although replies indicated that
your humble opinion is definitely not shared by everyone interested.
where exactly including brends and major/minor versions.
I fail to catch the meaning of this sentence. Probably you mean I have to
prove something here. Well, I don't. I did anyway on occasion here in the
hope you might learn from that.
In many cases the issue will desappear by itself just because you'll not
be willing to get funny on public by showing *what* browser you're hiding
you personal preferences behind of.
You express yourselves to the degree you appear to be able to understand the
matters discussed here.
hasOwnProperty() method deals with script objects *only*
What exactly are you calling a "script object"?
and it doesn't work for DOM interface check,
That depends on what DOM we are talking about.
which we are discussing now
Ohh, thank you very much for telling me what we were *really* discussing.
IYVHO.
(try hasOwnProperty on window).
this.hasOwnProperty('window') in global context yields `true' here
[Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922
Firefox/1.0.7 (Debian package 1.0.7-1) Mnenhy/0.7.2.0].
Since `window' is a property of the Global Object in almost all
HTML DOMs including the Gecko DOM, that result is correct.
The same goes for window.hasOwnProperty("document").
It does not for document.hasOwnProperty("images") and other
HTMLCollections.
IN method covers both cases.
It does, but you are still missing the point.
PointedEars
