Prev: customerisnotalwaysright.
Next: background image
From: Matthias Watermann on 6 May 2008 03:31
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
/ \
From: Henry on 6 May 2008 06:05
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?
From: VK on 6 May 2008 06:09
On May 6, 11:31 am, Matthias Watermann <li...(a)mwat.de> wrote:
> 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.
From: Matthias Watermann on 6 May 2008 07:25
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
/ \
From: VK on 6 May 2008 08:00
On May 6, 3:25 pm, Matthias Watermann <li...(a)mwat.de> wrote:

> 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/Accessing_Web_Services_in_Mozilla_Using_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.
 |  Next  |  Last
Pages: 1 2
Prev: customerisnotalwaysright.
Next: background image