Proposal: A way to assign a unique id to JS objects

[javadesigner]

A proposal to standarize (by convention) giving javascript objects a
unique 'id'. This is useful when doing object comparisons etc. (one
can use === but this prints out better when debugging, I think)

------------------------- set id -----------------------------
function setid(o) {
if (o.id)
return o;
if (! window._idcount)
window._idcount = 1;
o.id = "id: " + window._idcount++ + '/' +
Object.prototype.toString.call(o);
return o;
};
-----------------------------------------------------------------

Example Usage:

function foo() {
setid(foo.prototype);
};

var f1 = new foo();
setid(f1);

alert(foo.prototype.id)
alert(f1.id)

Comments and thoughts ?

Best regards,
--j

 

[Thomas 'PointedEars' Lahn]

A proposal to standarize (by convention) giving javascript objects a
unique 'id'. This is useful when doing object comparisons etc.

Objects *have* identity already.

(one can use ===

One can even use `==' for comparing object references.

but this prints out better when debugging, I think)

What you are missing is that the same object can be referred to
by different properties, some of which do not need to have a name.

------------------------- set id -----------------------------
function setid(o) {
if (o.id)
return o;
Pardon?

if (! window._idcount)
window._idcount = 1;

OMG. It's a *host* object.

o.id = "id: " + window._idcount++ + '/' +
Object.prototype.toString.call(o);

Object.prototype.toString.call(...) is superfluous as a quick test would
have showed you had you not already known from the Specs and docs. And if
the object already has an `id' property, you overwrite it. Great. NOT.

return o;

This is supposed to be a setter. It should return a value that allows the
caller to determine if setting the property was successful, or it should
throw an exception or not to that end. Programming 101.

};
[...]
var f1 = new foo();
setid(f1);

Setting the `id' can and should be facilitated in the constructor, which
should be referred to using a property that has a name starting with a
capital letter. Being a "Java designer" (unless that supposed nick name is
a sign of your cluelessness -- Java != JavaScript), you should know about
that pattern and that convention.

alert(foo.prototype.id)
alert(f1.id)

It's still window.alert(...).

Comments and thoughts ?

You should RTFM, RTFFAQ, STFW before you try to improve the language.


PointedEars

 

[javadesigner]

function setid(o) {

Pardon?

One can simply return nothing of course, i return the same object,
just in case, optionally, someone
wants to say:

alert(setid(some_object))

OMG. It's a *host* object.

Yeah, so ? I want, specifically, to run inside a browser.

Object.prototype.toString.call(...) is superfluous as a quick test would
have showed you had you not already known from the Specs and docs. And if
the object already has an `id' property, you overwrite it. Great. NOT.

Object.prototype.toString.call() prints the [[classname]]

This is supposed to be a setter. It should return a value that allows the
caller to determine if setting the property was successful, or it should
throw an exception or not to that end. Programming 101.

See above.

Setting the `id' can and should be facilitated in the constructor, which
should be referred to using a property that has a name starting with a
capital letter. Being a "Java designer" (unless that supposed nick name is
a sign of your cluelessness -- Java != JavaScript), you should know about
that pattern and that convention.

Java, Actionscript and many other languages (for example) have
a native object reference identity (that looks like, for example,
0xaadc30) that
JS objects do not expose. This idea is to allow JS objects to also
have a
pseudo object (reference) identity.

Best regards,
--j

 

[Thomas 'PointedEars' Lahn]

Are you even aware that {id: 0} will not pass?

One can simply return nothing of course,

One cannot return nothing. RTFM.

And again: It's a setter. It's supposed to return a value that indicates
success or failure of setting or `undefined' (which is the default). It's
not supposed to return the argument value regardless.

i return the same object,

To what end? And the pronoun is spelled with a capital letter.

just in case, optionally, someone wants to say:

alert(setid(some_object))

What for? And it's still window.alert(...).

Yeah, so ? I want, specifically, to run inside a browser.

RTFM, RTFFAQ, STFW. Host objects SHOULD NOT be augmented because they may
implement any internal [[Put]] algorithm, much in contrast to native objects
which MAY be augmented because they MUST follow the specified algorithm in
that regard.

Object.prototype.toString.call(...) is superfluous as a quick test would
have showed you had you not already known from the Specs and docs. And if
the object already has an `id' property, you overwrite it. Great. NOT.

Object.prototype.toString.call() prints the [[classname]]

It doesn't, RTFM. It may print the value of the internal [[Class]]
property, but with native user-defined objects it will always print "[object
Object]", if that. With host objects, the result is unspecified and
therefore rather meaningless. And despite the name `[[Class]]', it is a
specification for a prototype-based language.

See above.

There is no rationale for it above. And it's still nonsense.

Java, Actionscript and many other languages (for example) have

It's ActionScript, and since it's an ECMAScript implementation as well, it
is supposed to work internally much like JavaScript, for example. It's the
runtime environment that exposes the information, not the language.

a native object reference identity (that looks like, for example,
0xaadc30) that JS objects do not expose.

You don't know what you are talking about. {} != {}.

This idea is to allow JS objects to also have a pseudo object (reference)
identity.

You don't seem to refer to a word I wrote above. In any case, what is this
needed for, where is your rationale? That a thing can be achieved is no
reason that it needs to be achieved.


PointedEars

 

[javadesigner]

Are you even aware that {id: 0} will not pass?

That's a good catch. The test should be

if (o.id != undefined) {
...
}

One cannot return nothing. RTFM.
return;

And again: It's a setter. It's supposed to return a value that indicates
success or failure of setting or `undefined' (which is the default). It's
not supposed to return the argument value regardless.

A setter is not "supposed" to do anything specific. Many people
expose properties using so-called setters/getters but that is non
object oriented
programming (google 'set/get evil') and its pros/cons is a discussion
left for another day.

Don't think of setid as a "setter" just because it has "set" in the
name. Change it to
fixid or whatever.

To what end? And the pronoun is spelled with a capital letter.

or:
fix_id
FIXid
or whatever.

The name of the method chosen there was arbitrary and not relevant to
the purpose of the method.

What for? And it's still window.alert(...).

Debugging. Seeing what's going on at some point in the program. Etc.

RTFM, RTFFAQ, STFW. Host objects SHOULD NOT be augmented because they may
implement any internal [[Put]] algorithm, much in contrast to native objects
which MAY be augmented because they MUST follow the specified algorithm in
that regard.

I see. In that case, instead of window.id, maybe something like this:

var id_generator = id_generator || { id: 0 };

Object]", if that. With host objects, the result is unspecified and
therefore rather meaningless.

Unspecified doesn't mean not useful in practice.

It's ActionScript, and since it's an ECMAScript implementation as well, it
is supposed to work internally much like JavaScript, for example. It's the
runtime environment that exposes the information, not the language.

That's a good point (in Actionscript). For Java, the language exposes
this
(hashCode and System.identityHashCode)

You don't know what you are talking about. {} != {}.
?

You don't seem to refer to a word I wrote above. In any case, what is this
needed for, where is your rationale? That a thing can be achieved is no
reason that it needs to be achieved.

It just seems like an easy way to if an object is what I expect it to
be, identity wise, when
debugging or writing a program. One can also do the same thing, I
suppose, with tweaking
toString() but then, if an object already has toString() defined, then
one has to save the
existing toString() via a closure and then append that to the identity
pseudo-hashcode toString
it is replaced with.

I don't know, it just seemed like something useful to do, by
convention.

 

[Thomas 'PointedEars' Lahn]

That's a good catch. The test should be

if (o.id != undefined) {
...
}

No, it should not, as discussed recently *again*.

return;

That returns `undefined'. RTFM.

A setter is not "supposed" to do anything specific.

You must be kidding. A setter is supposed to set a property value or not,
and it is supposed to indicate by return value or exception if that was
successful.

Many people expose properties using so-called setters/getters but that is non
object oriented programming

Utter nonsense. Encapsulation which is a core principle of OOP *requires*
getters and setters for properties. And, in fact, ECMAScript editions and
some implementations have recognized that already.

(google 'set/get evil')

Google yourself. You have pretty much catching up to do.

and its pros/cons is a discussion left for another day.

There are no pros/cons with regard to OOP.

Don't think of setid as a "setter" just because it has "set" in the
name. Change it to fixid or whatever.

You are evading. Its name indicates (as it should) what it does: setting a
property.

or:
fix_id
FIXid
or whatever.

Again you are not referring to what you are quoting. If you want to talk to
yourself, I suggest you stand before a mirror instead.

The name of the method chosen there was arbitrary and not relevant to
the purpose of the method.
Nonsense.


Debugging. Seeing what's going on at some point in the program. Etc.

You don't know what you are talking about.

RTFM, RTFFAQ, STFW. Host objects SHOULD NOT be augmented because they may
implement any internal [[Put]] algorithm, much in contrast to native objects
which MAY be augmented because they MUST follow the specified algorithm in
that regard.

I see. In that case, instead of window.id, maybe something like this:

var id_generator = id_generator || { id: 0 };

Maybe. A better way would be to have the counter as a property of the
native Function object that is the constructor, since that ID would matter,
if that, only between objects created using the same constructor.

Object]", if that. With host objects, the result is unspecified and
therefore rather meaningless.

Unspecified doesn't mean not useful in practice.

You don't know what you are talking about.

That's a good point (in Actionscript). For Java, the language exposes
this (hashCode and System.identityHashCode)

Those are hashing functions and thus far from being symmetrical.

?

Try it.

It just seems like an easy way to if an object is what I expect it to
be, identity wise, when debugging or writing a program.

It is seldom, if ever, needed. RTFFAQ, especially about debugging, before
you vent more hot air here.


PointedEars

 

[javadesigner]

Here is a modified/cleaner version to try folks...try this in firebug
or your favorite JS console.

Comments/suggestions from other folks appreciated..

----------------------------------------------------------------------

var setid_count = setid_count || { id: 0 };
function setid(o) {
if (o.id != undefined) {
return o;
}
o.id = "id: " + setid_count.id++ + '/' +
Object.prototype.toString.call(o);
return o;
};

setid({}).id
var b = { toString : function() { return "hello"; } }
setid(b).id
setid(b).id

 

[javadesigner]

Actually, in the above post, I made a typo..replace
Object.prototype.toString.call(o) with toString()

 

[javadesigner]

Utter nonsense. Encapsulation which is a core principle of OOP *requires*
getters and setters for properties. And, in fact, ECMAScript editions and
some implementations have recognized that already.

You don't appear to understand OO or encapsulation at all. Hiding is
the
opposite of exposing, in OO one tells objects to do something
(behavior), not
willy-nilly expose internal state of your objects via getters/setters.

Those are hashing functions and thus far from being symmetrical.

And you don't understand Java at all, either (not that it's relevant
here). The
default hashCode and idenityHashCode use object references. And the
word "symmetry" doesn't even make sense in that sentence.

Best regards,
--j

 

[Lasse Reichstein Nielsen]

You must be kidding. A setter is supposed to set a property value or not,
and it is supposed to indicate by return value or exception if that was
successful.

There are several styles for writing "setters" (which really only differ
in what they return).
You mention two (return nothing, return whether setting succeeds, if it is
possible that it can't).
A third style is returning the object itself, to allow for method
chaining, e.g., foo.setX(42).setY("banana"). It is being used in practice.
Whether one like it or not is a matter of taste.

There are no pros/cons with regard to OOP.

Sorry, this is programming, not religion. Nothing is absolute.

/L

 

[Garrett Smith]

A proposal to standarize (by convention) giving javascript objects a
unique 'id'. This is useful when doing object comparisons etc. (one
can use === but this prints out better when debugging, I think)

Why can't you use toString for debugging?

That's pretty typical Java design.

------------------------- set id ----------------------------- [...]


Comments and thoughts ?

YAGNI.

Garrett

 

[Thomas 'PointedEars' Lahn]

I should have seen this coming ...

Utter nonsense. Encapsulation which is a core principle of OOP *requires*
getters and setters for properties. And, in fact, ECMAScript editions and
some implementations have recognized that already.

You don't appear to understand OO or encapsulation at all. Hiding is
the opposite of exposing, [...]

YMMD. And now FOAD, please.


PointedEars

 

[Jorge]

There are several styles for writing "setters" (which really only differ
in what they return).
You mention two (return nothing, return whether setting succeeds, if it is
possible that it can't).
A third style is returning the object itself, to allow for method
chaining, e.g., foo.setX(42).setY("banana"). It is being used in practice..
Whether one like it or not is a matter of taste.

Of course.

And a property 'setter' (method) is most often used when as a
consequence of updating the value of the property, there are a number
of additional actions to take(1). Or when the property being set is a
private one. If not you're better done setting the property directly
instead of doing it through a setter method.

(1)

e.g.

order= {
numberOfItems: 10,
priceEach: 1,
totalPrice: 10
};

order.numberOfItems would be better set with a setter method, so that
totalPrice gets updated automatically:

order.setNumberOfItems= function (p) {
this.numberOfItems= p;
this.totalPrice= p* this.priceEach;
return this;
};