[Pybeep-devel] Re: the devel list

[Sean A. <ze...@wo...>]

On Wed, 2002-01-30 at 07:29, Gabe Wachob wrote:
> You are saying that in the java beepcore, there is a MessageMSG class.
yes.=20
> I agree that there shuold be the sendXXX methods in a class corresponding
> to a channel.

> Instead of calling it a MessageMSG, how about a "RepliableMessage" or
> something like that which is a mixin (Pythonic!!!) class when a Message
> happens to be of type MSG?  (line 254 of channel.py)
so, we create a message. with possible mixin (nice idea!) that contains
functionality for sending message:
so, Message actually becomes a factory that returns an object correctly=20
initialised

(pseudo code)
...
message =3D Message(somechan, msgno, stream, MSG_TYPE_RPY)
|___
	step in...
	Message.__init__(args):
		(syncronized?)
		msgobj =3D self.__BlankMSG()
		msgobj.addBaseClass(ReplyMSG())
		msgobj.init(args)
		return msgobj

...
are we on the same page.

might be a little long winded, but it is certainly cleaner, (and more
OO, whatever that means, probably patternly correct too!!! ;-)

I very much like factory's as a way to build objects, it really cuts
down on possible programmer error.

> Notice also that there are separate replyListener and messageListener
> "interfaces" (Python doesn't formally separate interfaces from classes
> which I would call a drawback, actually). Not sure why this is importnat
> -- thought I'd just mention it.

I could be wrong, but,=20
Message Listener listens for MSG
ReplyListener listens for RPY, ANS, ERR, NUL

I normally use a mixin and then override for interfaces in py, its more
a contract showing how to use object than the way it is done in Java.
but it seems to work ok.

Sean
> So, basically, yes, lets move the sendNUL, sendANS, sendRPY methods
> elsewhere (sendERR probably goes everywhere).
>=20
> 	-Gabe
>=20
> On 30 Jan 2002, Sean Allen wrote:
>=20
> > It's been working fine for me ;-)
> >
> > About the Messages. basically, the functionality to respond to MSG's
> > that we have in Channel is now in a class called MessageMSG, which
> > represents a recieved MSG and contains logic to reply to it (sendXXX).
> > other Messages just become a Message (which doesn't really do much). I
> > was wondering if we should break the stuff in channel.Channel out into
> > another class in message.py, or unify it into a single Message class
> > that handles all of the above.
> >
> > Sean
> >
> > On Tue, 2002-01-29 at 23:42, Gabe Wachob wrote:
> > > DUH!
> > >
> > > I created the list, but apparenlty I have to then subscribe to it
> > > separately (even though it lets me *send* to the list without subscri=
bing
> > > egad).
> > >
> > > OK, now I'm subscribed.
> > >
> > > I'm not sure I followed that last email (your reply to your post abou=
t re:
> > > Messages)...
> > >
> > > 	-Gabe
> > >
> > > --
> > > Gabe Wachob                   gw...@wa...
> > > Personal                   http://www.wachob.com
> > > CTO, WiredObjects    http://www.wiredobjects.com
> > >
> >
> >
>=20
> --=20
> Gabe Wachob                   gw...@wa...
> Personal                   http://www.wachob.com
> CTO, WiredObjects    http://www.wiredobjects.com
>=20