Re: [Pybeep-devel] Re: the devel list

[Gabe W. <gw...@wa...>]

[Welcome to all the new pybeep-devel subscribers]

Sean-
	Everything sounds good except that I'm wondering if using __init__
as a factory method is a good idea. If I call a constructor on a class,
(ie Message()) I almost always expect to get back an instance of that
class.

	Perhaps there should be a MessageFactory class which has a
"static" (though of course, there ain't such a thing in Python) method
makeMessage()?

	-Gabe

On 30 Jan 2002, Sean Allen wrote:

> 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.
> > 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
> initialised
>
> (pseudo code)
> ...
> message = Message(somechan, msgno, stream, MSG_TYPE_RPY)
> |___
> 	step in...
> 	Message.__init__(args):
> 		(syncronized?)
> 		msgobj = 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,
> 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).
> >
> > 	-Gabe
> >
> > On 30 Jan 2002, Sean Allen wrote:
> >
> > > 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 subscribing
> > > > egad).
> > > >
> > > > OK, now I'm subscribed.
> > > >
> > > > I'm not sure I followed that last email (your reply to your post about re:
> > > > Messages)...
> > > >
> > > > 	-Gabe
> > > >
> > > > --
> > > > Gabe Wachob                   gw...@wa...
> > > > Personal                   http://www.wachob.com
> > > > CTO, WiredObjects    http://www.wiredobjects.com
> > > >
> > >
> > >
> >
> > --
> > Gabe Wachob                   gw...@wa...
> > Personal                   http://www.wachob.com
> > CTO, WiredObjects    http://www.wiredobjects.com
> >
>
>

-- 
Gabe Wachob                   gw...@wa...
Personal                   http://www.wachob.com
CTO, WiredObjects    http://www.wiredobjects.com