[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Messages

This message is going to look a little odd since I am actually just
forwarding a failiure notice I got
after putting the wrong username up top.   Hope no one minds.

-- BEGIN included message

Hi. This is the qmail-send program at sunsite.auc.dk.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<penginplay@sunsite.auc.dk>:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <s369625@student.uq.edu.au>
Received: (qmail 22921 invoked from network); 14 Jun 1998 20:09:45 -0000
Received: from student.uq.edu.au (root@130.102.2.20)
  by sunsite.auc.dk with SMTP; 14 Jun 1998 20:09:45 -0000
Received: from student.uq.edu.au (laaratna.staff.uq.edu.au [172.22.13.228])
	by student.uq.edu.au (8.8.8/8.8.7) with ESMTP id PAA00948
	for <penginplay@sunsite.auc.dk>; Sun, 14 Jun 1998 15:41:50 +1000 (GMT+1000)
Sender: raka@student.uq.edu.au
Message-ID: <3582D101.DE0DCF42@student.uq.edu.au>
Date: Sat, 13 Jun 1998 19:20:33 +0000
From: Adrian Ratnapala <s369625@student.uq.edu.au>
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586)
MIME-Version: 1.0
To: penginplay@sunsite.auc.dk
Subject: Messaing system.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Someone wrote in about the proposed messaging system,  I can't actually
access that message, so I'll just
have to write from memory.


Their concern was that message receivers had to inherit from the class
ppMessageReceiver, or something
like that.  The writer pointed to a document discussing this issue.
That document gave an example something
like this:


//This class is a message sender.
class Button{
    class MessageReceiver{

    }
    ...
    Send_Pressed();
};



class CDPlayer{

   //Some stuff in here.
   //A CD player is as yet incapable of receiving messages from the
button.
};


class MyCDPlayer : public CDPlayer,  virtual Button::MessageReceiver(){
    //This CD Player can get messages from buttons.
}


Then you somehow make that but the Start/Stop button of the CD player.
The author of the document correctly said that was stupid.   The main
problem
is that a class which is to receive messages from buttons have to
inherit from
Button::MessageReceiver.  This forces you to resort to silly things like
MyCDPlayer.
As you can imagine this would get unmanageable if you have to receive
messages
from many different kinds of objects, possibly bound at runtime.


The system we have is no nearly so brainded.  It is in fact essentially
the same as the system
which is advocated in that document.  In the current PenguinPlay system
it is necassary
for an object which can receive messages to derive from
ppMessageReceiver.  This class is
generic, the receiver does not care what type the sender of the message
was.   So we would
just do:

class CDPlayer : virtual ppMessageRecevier.
not          Button::MessageReceiver.

The requirement that a receiver derive from ppMessageReceiver is due to
an added
feature we have,  that is, when a receiver is destroyed, the connection
between it and the
sender is automatically destroyed.

If we went without this feature we could get some lovely flexibilty.
Any member of any C++
class, or even just straight C functions could be used as message
receivers without having to be
modified or wrapped.   It would not be  difficult to add this
functionality to the existing system
anyway,  the question is whether it is worth it.

-- END included message