Name of class instance

[Matthias Watermann]

Hi,

I'm wondering if it's possible for an object to figure it's name.
for example:

function baseClass() {
// setup properties of "baseClass"
}
baseClass.prototype = {
aMethod: function() {
// do something using the name of the object
// that's an instance of this (or derived) class
// e.g.
// window.alert('my name is: "' + DUNNO + '"');
};
};

function childOne() {
// setup properties of "childOne"
}
childOne.prototype = new baseclass();

function childTwo() {
// setup properties of "childTwo"
}
childTwo.prototype = new baseclass();

var o1 = new childOne(), o2 = new childTwo();

Now when calling "o1.aMethod()" the "DUNNO" should be "o1" and the
same with "o2" respectively.

Is that possibly without having to force a "name" argument down the
inheritance tree?

--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST M$ ATTACHMENTS
/ \

[Henry]

On May 6, 8:31 am, Matthias Watermann wrote:

I'm wondering if it's possible for an object to figure
it's name.

Objects don't have names, unless you give them names in which case it
is as easy to figure those names out as you programmed it to be when
you gave them their names.

<snip>

var o1 = new childOne(), o2 = new childTwo();

Now when calling "o1.aMethod()" the "DUNNO" should be "o1"
and the same with "o2" respectively.

And after:-

var o = o1;

o.aMethod();

- what is supposed be appear?

[VK]

On May 6, 11:31 am, Matthias Watermann <[e-mail]:

Hi,

I'm wondering if it's possible for an object to figure it's name.
for example:

function baseClass() {
// setup properties of "baseClass"}

baseClass.prototype = {
aMethod: function() {
// do something using the name of the object
// that's an instance of this (or derived) class
// e.g.
// window.alert('my name is: "' + DUNNO + '"');
};

};

function childOne() {
// setup properties of "childOne"}

childOne.prototype = new baseclass();

function childTwo() {
// setup properties of "childTwo"}

childTwo.prototype = new baseclass();

var o1 = new childOne(), o2 = new childTwo();

Now when calling "o1.aMethod()" the "DUNNO" should be "o1" and the
same with "o2" respectively.

and with
var o1 = new childOne();
// ...
var foo = o1;
foo.aMethod();

what DUNNO should be, "o1" or "foo"?

From the other side if it is guaranteed that for each instance only
one reference will exist, then just hardcode it:

var o1 = new childOne("o1");

From my rather long experience which you are free to disregard of
course, the "necessity" to know the current instance reference
identifier is a strong indication that the current programming pattern
is targeted straight to hell where it will sooner or later ;-)
So it may be a good idea to stop right now so taking some more secure
direction. With the block schema explained more practical suggestions
could be given.

[Matthias Watermann]

On Tue, 06 May 2008 03:09:03 -0700, VK wrote:

[...]

>var o1 = new childOne(), o2 = new childTwo();

Now when calling "o1.aMethod()" the "DUNNO" should be "o1" and the
same with "o2" respectively.

and with
var o1 = new childOne();
// ...
var foo = o1;
foo.aMethod();

what DUNNO should be, "o1" or "foo"?

Theoretically "foo". But in practice I don't care as I do not use such
a construct. (No offence meant.)

From the other side if it is guaranteed that for each instance only
one reference will exist, then just hardcode it:

Well, as long as I had only one instance I did it that way. But now I
need multiple instances of (different) derived classes. So the
hardcoded singleton approach doesn't work for me.

Now, that I think of it, the whole inheritance thing is just a little
complication. The main question, however, is whether JavaScript
provides a way to let an object figure out its name. I understand
that's not the case, right?

[...]
From my rather long experience which you are free to disregard of
course, the "necessity" to know the current instance reference
identifier is a strong indication that the current programming pattern
is targeted straight to hell where it will sooner or later ;-)

Well, I can't reject that, of course. In my case the object's name
is needed for sending it (along with other data) back to the web-server
which returns a piece of JavaScript code invocing an instance method
(the name and API of which is defined by contract). And since there may
be several concurrent requests (by different objects) I've to make sure
somehow that each response reaches the respective requester.

I've thought about a static class method of the base class to be
called instead. But apart from the fact that such a class method
would have to keep track of all instanciations (and deletions) it
would still need some way to identify the object that's supposed
to handle the received data.

In case you can think of another approach I'd appreciate it. Any
pointers are welcome.
--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST M$ ATTACHMENTS
/ \

[VK]

On May 6, 3:25 pm, Matthias Watermann <[e-mail]:

The main question, however, is whether JavaScript
provides a way to let an object figure out its name. I understand
that's not the case, right?

Right - because there is not such thing as "instance name". In this
aspect Javascript is no any different from any other programming
language like say C++ or Java. There is an instance object, and a
reference to this instance can be assigned to different identifiers or
you even may keep it anonymous, say
(new childOne).aMethod();
- not to say this approach is used too often, just to help to separate
in your mind a reference identifier and the object itself.
Of course each instance has its own objectID (DispID) to distinguish
several instances of the same class, but it is an internal system
property which is not accessible from the language itself. Again, it
is not any different from other OO languages.

>

[...]
From my rather long experience which you are free to disregard of
course, the "necessity" to know the current instance reference
identifier is a strong indication that the current programming pattern
is targeted straight to hell where it will sooner or later ;-)

Well, I can't reject that, of course. In my case the object's name
is needed for sending it (along with other data) back to the web-server
which returns a piece of JavaScript code invocing an instance method
(the name and API of which is defined by contract). And since there may
be several concurrent requests (by different objects) I've to make sure
somehow that each response reaches the respective requester.

A month later I would suggest to use WebService mechanics for that,
but now I see confirmed that Firefox 3.x will not have it as a default
feature for whatever reason:
http://developer.mozilla.org/en/docs..._WSDL_Proxying

So just stick then with manually setting initial instance identifier
on object instantiation. It is very bad and all hell doors may get
loose if more than one reference to the same object, but if you are on
a time limit...

For a long right run it is not instance business to handle RMI (Remote
Method Invocation), they have to do their job right first. For RMI
there should be a separate dispatcher. This way an instance sends
request to the dispatcher with reference to itself as request
consumer. The dispatcher then handles the request queue and returns
results to consumers by stored references.
This way you don't care what identifier(s) is(are) currently used to
hold a reference to the object which is the proper way to do things.

[Matthias Watermann]

On Tue, 06 May 2008 05:00:58 -0700, VK wrote:

[...]
For a long right run it is not instance business to handle RMI (Remote
Method Invocation), they have to do their job right first. For RMI
there should be a separate dispatcher. This way an instance sends
request to the dispatcher with reference to itself as request
consumer. The dispatcher then handles the request queue and returns
results to consumers by stored references.
This way you don't care what identifier(s) is(are) currently used to
hold a reference to the object which is the proper way to do things.

Ah, thank you very much! I definitely like such an approach. Quite
possibly that would allow for omitting the whole inheritance stuff and
use a design-by-contract model instead. Hmm, the more I think of it
the more charming it becomes ...
--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST M$ ATTACHMENTS
/ \

[sheldonlg]

Matthias Watermann wrote:

On Tue, 06 May 2008 05:00:58 -0700, VK wrote:

>[...]
For a long right run it is not instance business to handle RMI (Remote
Method Invocation), they have to do their job right first. For RMI
there should be a separate dispatcher. This way an instance sends
request to the dispatcher with reference to itself as request
consumer. The dispatcher then handles the request queue and returns
results to consumers by stored references.
This way you don't care what identifier(s) is(are) currently used to
hold a reference to the object which is the proper way to do things.

Ah, thank you very much! I definitely like such an approach. Quite
possibly that would allow for omitting the whole inheritance stuff and
use a design-by-contract model instead. Hmm, the more I think of it
the more charming it becomes ...

Try this one line:

<input type="button" onclick="alert('My name is ' + this.id)" id="foo"
value="Click Me">

and see what happens for you. Yes, each tag needs to be given a name
for this to work, but if you want a generic javascript with a generic
calling method, the use of "this" will work and give you the objects id.

[Matthias Watermann]

On Tue, 06 May 2008 10:48:00 -0400, sheldonlg wrote:

>>[...]
For a long right run it is not instance business to handle RMI (Remote
Method Invocation), they have to do their job right first. For RMI
there should be a separate dispatcher. This way an instance sends
request to the dispatcher with reference to itself as request
consumer. The dispatcher then handles the request queue and returns
results to consumers by stored references.
This way you don't care what identifier(s) is(are) currently used to
hold a reference to the object which is the proper way to do things.

Ah, thank you very much! I definitely like such an approach. Quite
possibly that would allow for omitting the whole inheritance stuff and
use a design-by-contract model instead. Hmm, the more I think of it
the more charming it becomes ...

Try this one line:

<input type="button" onclick="alert('My name is ' + this.id)" id="foo"
value="Click Me">

and see what happens for you. Yes, each tag needs to be given a name
for this to work, but if you want a generic javascript with a generic
calling method, the use of "this" will work and give you the objects id.

My markup doesn't contain any "onXXX" attributes since I prefer to clearly
separate markup (HTML), presentation (CSS) and behaviour (JavaScript). But
I see your point. However, my objects are not tied to a certain tag (i.e.
its JavaScript/DOM incarnation); sometimes they may handle several page
elements - like, say all anchors - sometimes they become active somewhere
in the event chain controlled by the respective method arguments. So it's
not a tag identifier I was looking for (that's easy enough as you pointed
out) but the name of a JavaScript object which I intended to send to the
remote server. Thanks for your thoughts anyway.
--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST M$ ATTACHMENTS
/ \

[Thomas 'PointedEars' Lahn]

Matthias Watermann wrote:

On Tue, 06 May 2008 03:09:03 -0700, VK wrote:

>[...]

>>var o1 = new childOne(), o2 = new childTwo();

Now when calling "o1.aMethod()" the "DUNNO" should be "o1" and the
same with "o2" respectively.

and with
var o1 = new childOne();
// ...
var foo = o1;
foo.aMethod();

what DUNNO should be, "o1" or "foo"?

Theoretically "foo". But in practice I don't care as I do not use such
a construct. (No offence meant.)

You miss the point. Objects just don't have names, they have identity.
Properties have names. Object references can be values of properties, and
there can be any number of different properties referencing the same object.
To keep track of all of them would require you to implement a record object
that is used every time a property of an object is added, modified or
deleted. And that is not only impossible as there are built-in objects and
host-defined properties, but the result retrieved then would be far from
being usable for debugging.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16