Eventmachine talk - Oct 2007 - [Fwd: Connection handler: mixin vs subclass]

An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071015/b51cdc1a/attachment.html

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::DorkbusterClientHandler) 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

On 10/15/07, Mark Zvilius <zvilius at earthlink.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

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-bounces at rubyforge.org
[mailto:eventmachine-talk-bounces at rubyforge.org] On Behalf Of Bill Kelly
Sent: Monday, October 15, 2007 3:29 PM
To: eventmachine-talk at rubyforge.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.

On 10/15/07, Mark Zvilius <zvilius at earthlink.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071016/cbdeb066/attachment.html