|
List Info
Thread:
|
|
|
 
United States |
2007-10-15 16:51:53 |
|
As my original post didn't engender any response, let me rephrase:
In what situations have people found it useful to subclass the
Connection class,
as opposed to using a mix-in Module?
Thanks,
Mark Zvilius
-------- Original Message --------
My work with EventMachine is getting more complex, and I have a question
about "best practice."
It is becoming impractical, with a more complex application, to handle
everything in the Module that is mixed-in to the Connection class. I
need to transfer data with the rest of the app.
Is it time to subclass the Connection class, or are there techniques
that escape me for getting objects in and out of the Connection class
using the mix-in Module?
Thanks,
Mark Zvilius
|
| Re: |
United States |
2007-10-15 17:28:32 |
From: Mark Zvilius
>
> As my original post didn't engender any response, let
me rephrase:
>
> In what situations have people found it useful to
subclass the Connection
> class, as opposed to using a mix-in Module?
Hmm. I'm fairly sure there was a reason I started
subclassing instead of
using the Module approach, but I can't recall what it was.
These days it's probably just a habit. I have noticed,
however, the
following "owner init" pattern popping up in a lot
of my EventMachine
connection handlers:
class DorkbusterClientHandler < EventMachine::Connection
def owner_init(owner, logger)
 owner = owner
logger = logger
csapi = ClientServicesAPI.new(owner, self, self)
remote_port, remote_ip =
Socket.unpack_sockaddr_in(self.get_peername)
log("incoming connection")
reset_state_term_init
end
# ...
end
EventMachine::start_server(host, listen_port, DB: orkbuste
rClientHandler) do |conn|
add_client(conn)
conn.owner_init(self, logger)
end
That is, I often want the spawned connection handler object
to be
initialized with some tie to some parent object that
"owns" that
connection.
Regards,
Bill
_______________________________________________
Eventmachine-talk mailing list
Eventmachine-talkrubyforge.org
http://rubyforge.org/mailman/listinfo/eventmachine-talk
|
|
| Re: |
|
2007-10-15 17:29:12 |
On 10/15/07, Mark Zvilius <zviliusearthlink.net> wrote:
>
> As my original post didn't engender any response, let
me rephrase:
>
> In what situations have people found it useful to
subclass the Connection class,
> as opposed to using a mix-in Module?
I wasn't sure exactly what you were asking in the first
post.
I almost always subclass.
class ClusterProtocol < EventMachine::Connection
# ...
end
I just like how it looks that way.
Kirk Haines
_______________________________________________
Eventmachine-talk mailing list
Eventmachine-talkrubyforge.org
http://rubyforge.org/mailman/listinfo/eventmachine-talk
|
|
| Re: |
United States |
2007-10-15 18:19:17 |
Yeah, that "owner init" scheme is what I came up
with too, in order to tie
the comms to the rest of the app. But it works just fine
with either the
mix-in or the subclass.
I'll still be interested to hear if anyone has a concrete
reason to subclass
vs. mix-in. I'm sure there are good reasons, but I can't
think of any...
Thanks,
Mark Z.
-----Original Message-----
From: eventmachine-talk-bouncesrubyforge.org
[mailto:eventmachine-talk-bouncesrubyforge.org] On Behalf Of
Bill Kelly
Sent: Monday, October 15, 2007 3:29 PM
To: eventmachine-talkrubyforge.org
Subject: Re: [Eventmachine-talk] [Fwd: Connection handler:
mixin vs
subclass]
...
Hmm. I'm fairly sure there was a reason I started
subclassing instead of
using the Module approach, but I can't recall what it was.
These days it's probably just a habit. I have noticed,
however, the
following "owner init" pattern popping up in a lot
of my EventMachine
connection handlers:
... (example code) ...
That is, I often want the spawned connection handler object
to be
initialized with some tie to some parent object that
"owns" that
connection.
_______________________________________________
Eventmachine-talk mailing list
Eventmachine-talkrubyforge.org
http://rubyforge.org/mailman/listinfo/eventmachine-talk
|
|
| Re: |
|
2007-10-16 00:33:02 |
|
On 10/15/07, Mark Zvilius < zviliusearthlink.net">zviliusearthlink.net> wrote:
Yeah, that "owner init" scheme is what I came up with too, in order to tie
the comms to the rest of the app. But it works just fine with either the
mix-in or the subclass.
I'll still be interested to hear if anyone has a concrete reason to subclass
vs. mix-in. I'm sure there are good reasons, but I can't think of any...
The original pattern (using a Module) originally came from the desire to have a minimum useful EM program be extremely easy to read and understand. More or less the smallest amount of typing, if you will. That's the only reason to prefer a Module to a subclass of EM::Connection.
The emergence of the "owner_init"; pattern is pretty interesting, and I think it falls out of the fact that most of the key EM functions are module functions on the EventMachine module rather than instance variables of some object. This design choice too was originally made in order to cut down on the amount of work needed to make functional programs.
Occasionally I've wondered if might make sense to wrap the EM API in some more object-orientedness. EM::Timer and EM::PeriodicTimer are both classes (requiring an invocation of #new) that are light wrappers around EM#add_timer.
By the way, EM is equated to EventMachine now, so in real code you can save typing if you like, by writing:
class MyConnection < EM::Connection
...
end
|
[1-5]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|