By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,940 Members | 1,522 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,940 IT Pros & Developers. It's quick & easy.

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

P: n/a
lets say i have two objects with the same properties and rge same values
:

var o1={element:one, type:'keyup',code:82,action:setToRed};
var o2={element:one, 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 nameElement ?

only by testing obj.nodeName ?

--
Une Bévue
Jun 27 '08 #1
Share this Question
Share on Google+
11 Replies


P: n/a
un************@weltanschauung.com.invalid (Une Bévue) writes:
lets say i have two objects with the same properties and rge same values
:

var o1={element:one, type:'keyup',code:82,action:setToRed};
var o2={element:one, 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 nameElement ?

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?

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Jun 27 '08 #2

P: n/a
Joost Diepenmaat <jo***@zeekat.nlwrote:
>
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={element:one,
type:'keyup',code:82,action:setToRed,modifiers:{sh ift: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).
how could i know an Object is of type <tag nameElement ?

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?
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'...
--
Une Bévue
Jun 27 '08 #3

P: n/a
Joost Diepenmaat wrote:
un************@weltanschauung.com.invalid (Une Bévue) writes:
>lets say i have two objects with the same properties and rge same values
:

var o1={element:one, type:'keyup',code:82,action:setToRed};
var o2={element:one, 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.
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
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Jun 27 '08 #4

P: n/a
un************@weltanschauung.com.invalid (Une Bévue) writes:
Joost Diepenmaat <jo***@zeekat.nlwrote:
>>
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={element:one,
type:'keyup',code:82,action:setToRed,modifiers:{sh ift: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 | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Jun 27 '08 #5

P: n/a
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>>does it means the comparaison operates over references not "values"
???

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

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Jun 27 '08 #6

P: n/a
VK <sc**********@yahoo.comwrites:
On Apr 19, 11:39 pm, unbewusst.s...@weltanschauung.com.invalid (Une
Bévue) wrote:
>Ok, that's clear to me now, i have to compare only object like that :

var o1={element:one,
type:'keyup',code:82,action:setToRed,modifiers:{s hift: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.
You seem to be confused about what OO is and it is not at all strange or
unusual to create objects in this way.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Jun 27 '08 #7

P: n/a
Joost Diepenmaat <jo***@zeekat.nlwrote:
>
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.remo ve(o);};
....
}
the "constructor" is that "KeyEventDispatcher"
--
Une Bévue
Jun 27 '08 #8

P: n/a
Joost Diepenmaat <jo***@zeekat.nlwrote:
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.

--
Une Bévue
Jun 27 '08 #9

P: n/a
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';

?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jun 27 '08 #10

P: n/a
VK
On Apr 20, 1:04 am, Joost Diepenmaat <jo...@zeekat.nlwrote:
VK <schools_r...@yahoo.comwrites:
On Apr 19, 11:39 pm, unbewusst.s...@weltanschauung.com.invalid (Une
Bévue) wrote:
Ok, that's clear to me now, i have to compare only object like that :
var o1={element:one,
type:'keyup',code:82,action:setToRed,modifiers:{sh ift: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.

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

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
Jun 27 '08 #11

P: n/a
VK
On Apr 20, 12:39 pm, VK <schools_r...@yahoo.comwrote:
After a SC-diplomed exited explanation
"CS-diplomed"

dyslexia, damn it...

Jun 27 '08 #12

This discussion thread is closed

Replies have been disabled for this discussion.