Hi!
I don't even know how to name this post...:)
I have a list of classes, and I want a message from a class to be broadcast
to all the other classes in the list, except the one which sent it. I've
managed to obtain this using a delegate to a function in the container
class, which then "spread the words".
But my problem is to recognize who sent the message. I'm using an unique
number for each class added to the list, and this is used to recognize the
class, but I know this is not an elegant way.
Hence, I'm wondering if there's a way to obtain a pointer to the calling
class (the "this" in the title) in some implicit manner, or I have to give
to the delegate some sort of this flavoured variable,in which case,
which?:)

I hope I've been clear in the explanation of my problem!:)

thanks in advance!

Carotinho

Carotinho wrote:
> Hi!
> I don't even know how to name this post...:)
> I have a list of classes, and I want a message from a class to be broadcast
> to all the other classes in the list, except the one which sent it. I've
> managed to obtain this using a delegate to a function in the container
> class, which then "spread the words".

So, you have a list of... my guess would be Instances, that is objects?

Class is a sort of prototype to the objects, or class instances. But you can have classes stored in the collectiom too, for example by holding their classinfo. I would rather believe you don't, so disregard this paragraph if unclear. :>

So, you call the function in the container object which then calls a messaging function in each of the objects it holds?

> But my problem is to recognize who sent the message. I'm using an unique
> number for each class added to the list, and this is used to recognize the
> class, but I know this is not an elegant way.

Why don't you sort of include "this" (of type "YourClass") into the message instead of that serial number? Then, each recieving object can compare "this" in the message with its actual "this" by doind something like "if (this === message.sendingObjectsThis) return; //It's mine, i don't want it!". A further step would be to do this check in the sending function, a la "if (someObject !== message.sendingObjectsThis) someObject.sendMeMessage(message);

> Hence, I'm wondering if there's a way to obtain a pointer to the calling
> class (the "this" in the title) in some implicit manner, or I have to give
> to the delegate some sort of this flavoured variable,in which case,
> which?:)

The delegate gets the message, which includes the reference to the object. I think you need not include the sendingObjectsThis literally into the message, just pass it along with it, if you are deciding which objects need to recieve the message directly in the delegate.

> I hope I've been clear in the explanation of my problem!:)

If my answer answeres your question then yes. But frankly... well, you know...

There is a myriad of things you can do. You can store objects in containers, compare them, etc, this is all done by reference, so the separate instances are treated as different. If you want do differentiate by type instead of instance, every instance carries a reference to its type description, it is called classinfo and is of type ClassInfo and is a class.

I may have mixed up your mind but i suggest you take a look at object.d in Phobos. Look for definitions of classes Object and ClassInfo and things may become clear again.

-i.

Hi Ilya!

Ilya Minkov wrote:

> So, you have a list of... my guess would be Instances, that is objects?
> 
> Class is a sort of prototype to the objects, or class instances. But you can have classes stored in the collectiom too, for example by holding their classinfo. I would rather believe you don't, so disregard this paragraph if unclear. :>

No, no, it's clear, I have a list of objects, instanciated class:) I understand the difference, this is an error of mine due to my poor knowledge of right terms:)

> So, you call the function in the container object which then calls a messaging function in each of the objects it holds?

The path is that a object say something to the container, and then the container passes the messages to all the others object of the list

> Why don't you sort of include "this" (of type "YourClass") into the message instead of that serial number? Then, each recieving object can compare "this" in the message with its actual "this" by doind something like "if (this === message.sendingObjectsThis) return; //It's mine, i don't want it!". A further step would be to do this check in the sending function, a la "if (someObject !== message.sendingObjectsThis) someObject.sendMeMessage(message);

Ok I got the sense. It's precisely what I had in mind. But I don't know what the === is. Well, I've tried and everything's working right (^_^), but what's the name of that === operator?:)

> The delegate gets the message, which includes the reference to the object. I think you need not include the sendingObjectsThis literally into the message, just pass it along with it, if you are deciding which objects need to recieve the message directly in the delegate.

I can't get the point of this... do you mean that a objects should pass as
parameters this and the message like this:
void delegate(object, int) dg; => dg(this, message1)
?
I'm doing like this and it works, but maybe you mean that when the delegate
gets the message, this message includes somehow automagically the "this
pointer" of the caller?


> If my answer answeres your question then yes. But frankly... well, you know...

Yes you answered well:)

> There is a myriad of things you can do. You can store objects in containers, compare them, etc, this is all done by reference, so the separate instances are treated as different. If you want do differentiate by type instead of instance, every instance carries a reference to its type description, it is called classinfo and is of type ClassInfo and is a class.

this is another interesting opening... like having a race of class which can't understand the language of other classes... cool!:)

> 
> I may have mixed up your mind but i suggest you take a look at object.d in Phobos. Look for definitions of classes Object and ClassInfo and things may become clear again.

I'm already doing it:)

A lot of thanks for your patience and understanding, and for solving my doubts:)

Carotinho

Carotinho wrote:

> Ok I got the sense. It's precisely what I had in mind. But I don't know what
> the === is. Well, I've tried and everything's working right (^_^), but
> what's the name of that === operator?:)

The documentation, the section on operators explains it. === and !== operators are meaningful only on classes. Class instance is internally a reference (pointer) to a structure which holds the object fields and the pointer to class-related data. == and != operators on classes compare classes by value, by relying on opCmp overload. By default, opCmp is defined to be pointer comparison for classes, however be aware that should the left-hand-side object be null, == will segfault while trying to call opCmp for the object. === and !== compare object pointers directly, without going through a virtual function call.

> I can't get the point of this... do you mean that a objects should pass as
> parameters this and the message like this:
> void delegate(object, int) dg; => dg(this, message1)
> ?
> I'm doing like this and it works, but maybe you mean that when the delegate
> gets the message, this message includes somehow automagically the "this
> pointer" of the caller?

Yes, that's how i would do it. But if message was not an integer but a struct, it might make sense to include this into the message. :>

>>ClassInfo and is a class.

Argh, not class but class instance, which is shared among all instances of the class it describes. Nontheless, you got it right.

> A lot of thanks for your patience and understanding, and for solving my
> doubts:)

Glad to be halpful.

-3yE (the evil twin of eye)

Ilya Minkov wrote:

> The documentation, the section on operators explains it.

Do you mean the section about operator overload? === it's in there, but it's
the kind of page I don't read since the need of overloading operators isn't
included in my usual and simple programming needs:)
But now I've understood what you're talking about.

Thanks again:)

Carotinho

Carotinho wrote:
> Do you mean the section about operator overload? === it's in there, but it's
> the kind of page I don't read since the need of overloading operators isn't
> included in my usual and simple programming needs:)
> But now I've understood what you're talking about. 

Perhaps the section of the documentation is somewhat misnamed.

The documentation for D is very short, and not particularly well organized. Due to its shortness, it is hoped for, and in fact expected, that the user reads it completely. You will definately find important warnings and relevant techniques even in chapters you find irrelevant for your current task. The documentation does not repeat itself, thus placing a burden at occasional reader but relieving a reader who wants to read it entirely.

Also wiki4d FAQs (http://www.prowiki.org/wiki4d/wiki.cgi) are very helpful.

-eye