meaning of "===" for objects ???

[Une Bévue]

lets say i have two objects with the same properties and rge same values
:

var o1={elementne, type:'keyup',code:82,action:setToRed};
var o2={elementne, type:'keyup',code:82,action:setToRed};

the variable "one" being a DIV Element and "setToRed" a function.

doing alert(o1===o2) gave me false.

does it means the comparaison operates over references not "values" ???

I need to have a proper comparator, saying "eql" for Objects containing
any king of values :

Number, string, date, object...

how could i know an Object is of type <tag name> Element ?

only by testing obj.nodeName ?

 

[Joost Diepenmaat]

lets say i have two objects with the same properties and rge same values
:

var o1={elementne, type:'keyup',code:82,action:setToRed};
var o2={elementne, type:'keyup',code:82,action:setToRed};

the variable "one" being a DIV Element and "setToRed" a function.

doing alert(o1===o2) gave me false.

does it means the comparaison operates over references not "values"
???

Depends on the type of object. For the *exact* meaning, see ecma-262
section 11.9.6.

Simplified (IOW incorrect; rule of thumb): if o1 and o2 are both strings
or (not NaN) numbers, o1 === o2 is true if they are of the same
value. If o1 and o2 are of type Object, it's only true if they are the
*same* object.

I need to have a proper comparator, saying "eql" for Objects containing
any king of values :

Number, string, date, object...

There isn't any such comparator. IME the you only actually need such a
very general comparator in very specific library routines such as
general object serializers. You don't really need it in day-to-day
programming.

how could i know an Object is of type <tag name> Element ?

only by testing obj.nodeName ?

Seems like a fairly good choice, assuming I understand you
correctly. How does that relate to the rest of your post?

 

[Une Bévue]

There isn't any such comparator. IME the you only actually need such a
very general comparator in very specific library routines such as
general object serializers. You don't really need it in day-to-day
programming.

Ok, that's clear to me now, i have to compare only object like that :

var o1={elementne,
type:'keyup',code:82,action:setToRed,modifiers:{shift:false,alt:false}};


then with Strings, Numbers Simple Objects having boolean values, string
or number, Function (in this case "setToRed") and DOM Element (in this
case "one" is a DIV).

Seems like a fairly good choice, assuming I understand you
correctly. How does that relate to the rest of your post?

because i need to compare objects having DOM Element as value of a
property and experimetally i've found the comparaison between to DOM
Elements is correct, surprisingly (ie
toto=document.getElementById('toto') is "===" to
anotherToto=document.getElementById('toto').

in the above ewample the way i do the "comparator" is (simplified) :

- compare with null both sides;
- if both objects have the property 'nodeName' I'll compare the object
identity like that : anObject===anotherObject
- if not and it is an object, I'll compare all property/value pairs
recursively, like that :
if(!(this[p].eql(o[p]))){return false;}

(my "comparator" is a prototype of Object :
Object.prototype.eql=function(o){...} the reason for this[p].eql(o[p])
replacing "this[p]===o[p]"


then i needed to know the best way to say 'this object is of type DOM
Element'...

 

[Thomas 'PointedEars' Lahn]

Depends on the type of object.

Actually, it does not. Since objects have identity, if there are two
different objects, both the `==' and `===' operations will result in
`false', no matter their constructor or prototype object.

For the *exact* meaning, see ecma-262 section 11.9.6.

Two references are equal if they refer to the same object. As simple as that.

Simplified (IOW incorrect; rule of thumb): if o1 and o2 are both strings
or (not NaN) numbers, o1 === o2 is true if they are of the same
value. If o1 and o2 are of type Object, it's only true if they are the
*same* object.

Strings and numbers are _not_ objects, they are primitive values. But
String *objects* and Number *objects* are objects, and the result of the
`==' and `===' operations is for them as with any object:

// false
new String("x") == new String("x")

Never confuse primitive values and objects in ECMAScript implementations,
especially avoid using an object where a primitive value suffices; if you
need the object's properties, you can use them in an expression anyway, for
example:

var x = 42.3234;

// 2
x.toFixed(2).toString().length

// 97
"a".charCodeAt(0)


PointedEars

 

[Joost Diepenmaat]

Ok, that's clear to me now, i have to compare only object like that :

var o1={elementne,
type:'keyup',code:82,action:setToRed,modifiers:{shift:false,alt:false}};


then with Strings, Numbers Simple Objects having boolean values, string
or number, Function (in this case "setToRed") and DOM Element (in this
case "one" is a DIV).

in that case you could compare each property in that list using ===
except, possibly, for the DOM element - see below.

because i need to compare objects having DOM Element as value of a
property and experimetally i've found the comparaison between to DOM
Elements is correct, surprisingly (ie
toto=document.getElementById('toto') is "===" to
anotherToto=document.getElementById('toto').

It's not all that surprising, since most browsers probably really do use
the same host object to refer to the same DIV. But as far as I know,
they're not *required* to do so, and even if they did, I'm not sure that
host objects are required to be === to themselves (though still, as far
as implementing them goes, it's probable that they are). If you're using
valid markup, and the DIVs you're comparing all have ID properties and
are in the same document, you could just compare the ID, since IDs
should be unique. IOW:

document.getElementById("bla").id == document.getElementById("bla").id

in the above ewample the way i do the "comparator" is (simplified) :

- compare with null both sides;
- if both objects have the property 'nodeName' I'll compare the object
identity like that : anObject===anotherObject

This might not be safe. See above.

- if not and it is an object, I'll compare all property/value pairs
recursively, like that :
if(!(this[p].eql(o[p]))){return false;}

As far as I can see from your types of properties, you can just do

if (this[p] !=== o[p]) return false;

(my "comparator" is a prototype of Object :
Object.prototype.eql=function(o){...} the reason for this[p].eql(o[p])
replacing "this[p]===o[p]"

I don't think you need that.

then i needed to know the best way to say 'this object is of type DOM
Element'...

In this case, I'd just check if the object as an id property; if so,
compare that, otherwise do object1 === object2. If you can control your
environment enough, that should work. If you can't control your
environment, that may not, but in that case, there's probably no general
solution.

 

[Joost Diepenmaat]

Actually, it does not. Since objects have identity, if there are two
different objects, both the `==' and `===' operations will result in
`false', no matter their constructor or prototype object.

You're right, I should have used the word "value" instead of
"object". But that would probably have been just as confusing in this
context, only in a different way.

 

[VK]

Ok, that's clear to me now, i have to compare only object like that :

var o1={elementne,
type:'keyup',code:82,action:setToRed,modifiers:{shift:false,alt:false}};

First of all you should not create objects like that, unless making a
small demo snippet for posting. In the real case you of course using
OOP - that removes the source of your problem.

<!DOCTYPE html>
<html lang="en-US">
<head>
<meta http-equiv="Content-type"
content="text/html; charset=iso-8859-1">
<title>Demo</title>
<script type="text/javascript">

var o1 = null;
var o2 = null;

function MyObject(elementDOM, eventType, action) {
this.elementDOM = elementDOM;
this.eventType = eventType;
elementDOM['on'+eventType] = MyObject[action];
}
MyObject.setToRed = function() {
this.style.color = 'red';
}
MyObject.setInvisible = function() {
this.style.visibility = 'hidden';
}

function init() {

o1 = new MyObject(
document.getElementById('p1'),
'click',
'setToRed');

o2 = new MyObject(
document.getElementById('p2'),
'click',
'setInvisible');

window.alert(o1 instanceof MyObject); // true
window.alert(o2 instanceof MyObject); // true
window.alert(o1 == o2); // of course false

}

function releaseContextAndInit() {
window.setTimeout('init()',10);
}
window.onload = releaseContextAndInit;
</script>
</head>
<body>
<p id="p1">Lorem</p>
<p id="p2">Ipsum</p>
</body>
</html>

 

[Joost Diepenmaat]

First of all you should not create objects like that, unless making a
small demo snippet for posting. In the real case you of course using
OOP - that removes the source of your problem.

You seem to be confused about what OO is and it is not at all strange or
unusual to create objects in this way.

 

[Une Bévue]

You seem to be confused about what OO is and it is not at all strange or
unusual to create objects in this way.

Yes, in my case (in fact what i have posted is somehow a test case), the
objects are "parameters" of other objects; that's the reason why i need
to "compare" them :

function KeyEventDispatcher(){
var _listeners=[];
this.addKeyListener=function(o){...}
this.removeKeyListener=function(o){_listeners.remove(o);};
....
}
the "constructor" is that "KeyEventDispatcher"

 

[Une Bévue]

If you're using
valid markup, and the DIVs you're comparing all have ID properties and
are in the same document, you could just compare the ID, since IDs
should be unique. IOW:

document.getElementById("bla").id == document.getElementById("bla").id

unfortunately, i can't, not all the DOM Element do have an id, only a
few.

 

[Evertjan.]

Joost Diepenmaat wrote on 19 apr 2008 in comp.lang.javascript:

document.getElementById("bla").id == document.getElementById("bla").id

Would that be different [in valid HTML] from:

var result = document.getElementById('bla') && 'bla' == 'bla';

?

 

[VK]

You seem to be confused about what OO is and it is not at all strange or
unusual to create objects in this way.

After a SC-diplomed exited explanation of benefits of closure-based
inheritance with memory leaking as a structural part of the
programming approach: I am ready to believe to anything - including
that I have no idea about OOP or even that OOP never existed and that
it was just a world-wide long lasting fraud. :-|
See also http://groups.google.com/group/comp.lang.javascript/msg/fa5f0379c069ac9c

My humble opinion is that Javascript last 2 years became a victim of
its own Eternal September. "AJAX" and "Web 2.0" brought into the land
never ending waves of C++ speaking and thinking people. The problem
with them is that they don't want to learn the language of the land
they came to, they have no respect to it of any kind and they are
absolutely sure of the superiority of their own mother tong. So the
maximum compromise they are ready for is to learn the basic
vocabulary: but the sentences they are making are in their own
language, with words automatically replaced by Javascript ones.
Respectively the quality of the outcome is equal to some automated
translation of say Japanese to French.
IMHO

 

[VK]

After a SC-diplomed exited explanation

"CS-diplomed"

dyslexia, damn it...