Eventmachine talk - Oct 2007 - start_server block executed in the wrong order?

I''m trying to initialize some connection data from the scope of where
the
run block is executing.  I saw this:

EventMachine::run {
    EventMachine::start_server( host, port, HTTPConnHandler ) {|conn|
        # conn is a newly-accepted instance of class HTTPConnHandler.
        # This block is called via instance_eval AFTER initialize,
        # and BEFORE Connection#post_init. This execution order is documented
        # and you can depend on it not changing.
    }
}

but ran into problems with it not behaving in the way described above.
Running the following test program:

http://pastie.caboo.se/109306

The order I''m getting is:

initialize called
post_init called
start_server block called

--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
720-227-0129 ext. 202
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071021/9454627e/attachment.html

On 10/21/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> I''m trying to initialize some connection data from the scope of
where the
> run block is executing.  I saw this:
>
> EventMachine::run {
>     EventMachine::start_server( host, port, HTTPConnHandler ) {|conn|
>         # conn is a newly-accepted instance of class HTTPConnHandler.
>
>         # This block is called via instance_eval AFTER initialize,
>         # and BEFORE Connection#post_init. This execution order is
documented
>         # and you can depend on it not changing.
>     }
> }
>
> but ran into problems with it not behaving in the way described above.
> Running the following test program:
>
> http://pastie.caboo.se/109306
>
> The order I''m getting is:
>
> initialize called
> post_init called
> start_server block called


This is bizarre. I''m fairly sure I wrote those comments you quoted
(because
they sound like my style) but I can''t find them anywhere in the source
code.
Where did you get that code snippet from?

At any rate, the comment is clearly wrong. Connection#post_init is called
from inside Connection#initialize (the base-class constructor, in case you
override it), and the block passed to start_server is called after the
constructor returns. This has to make sense, because the start_server block
receives (and has always received) the newly-created object of type
EM::Connection (or a subclass) as a parameter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071021/d06e47df/attachment.html

On 10/21/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
>
>
>
> This is bizarre. I''m fairly sure I wrote those comments you quoted
> (because they sound like my style) but I can''t find them anywhere
in the
> source code. Where did you get that code snippet from?
>
The mailing list archives:

http://rubyforge.org/pipermail/eventmachine-talk/2007-February.txt

At any rate, the comment is clearly wrong. Connection#post_init is
called
> from inside Connection#initialize (the base-class constructor, in case you
> override it), and the block passed to start_server is called after the
> constructor returns. This has to make sense, because the start_server block
> receives (and has always received) the newly-created object of type
> EM::Connection (or a subclass) as a parameter.
>
Okay, I''ll just move what I was going to place in post_into into
another
method and call that from the block...

--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
720-227-0129 ext. 202
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071021/b46cad61/attachment.html

On 10/21/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> On 10/21/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> >
> > At any rate, the comment is clearly wrong. Connection#post_init is
> > called from inside Connection#initialize (the base-class constructor,
in
> > case you override it), and the block passed to start_server is called
after
> > the constructor returns. This has to make sense, because the
start_server
> > block receives (and has always received) the newly-created object of
type
> > EM::Connection (or a subclass) as a parameter.
> >
>
> Okay, I''ll just move what I was going to place in post_into into
another
> method and call that from the block...
>

I''m giving serious thought to changing how this works because it seems
to
cause to serious inconvenience.

(Side point: it''s important for protocol handlers to be
"sense-neutral"
whenever possible, meaning that the same user code can be used either in a
network server or network client without change.)

Originally, the EventMachine::Connection class was "buried" (called
only by
the reactor, never by user code), and protocol handlers were developed by
writing Ruby Modules. Now, a lot of people subclass EM::Connection (often
because they need to do initializations and they want the other benefits of
writing a class).

I''m always troubled by the fact that you *must* remember to call super
in
your initialize method if you subclass EM::Connection. That''s one thing
I''d
like to change.

EM::Connection#post_init is currently called from *inside* the base class
constructor, but it could probably be moved outside of it and called
afterward. That would eliminate confusion about the behavior of #post_init
with respect to the positioning of the super call inside subclassed
constructors.

The major limitation of both the constructor (both base class and
subclassed) and of #post_init is that they''re called by the reactor
*with no
parameters.*

As long as that remains true, there will be a need for the block that is
passed to EM#start_server. It takes a parameter which is the newly-created
object, on which you can call any method, and it can be super-useful because
it''s a closure in the context where #start_server is called. It still
seems
to me that the most logical place to call the block is after #post_init is
called. Given all that, do we really need #post_init?

#post_init was originally invented because of protocol handlers that are
Modules rather than subclasses of EM::Connection. There was no way to
initialize these without #post_init. (Passing blocks to #start_server was
invented later.) I''m not proposing to eliminate #post_init, but
it''s
probably a good idea to avoid it in new code.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071022/b0b0dbda/attachment.html

On 10/22/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
>
> On 10/21/07, Tony Arcieri <tony at clickcaster.com> wrote:
> >
> > On 10/21/07, Francis Cianfrocca <garbagecat10 at gmail.com >
wrote:
> > >
> > > At any rate, the comment is clearly wrong. Connection#post_init
is
> > > called from inside Connection#initialize (the base-class
constructor, in
> > > case you override it), and the block passed to start_server is
called after
> > > the constructor returns. This has to make sense, because the
start_server
> > > block receives (and has always received) the newly-created object
of type
> > > EM::Connection (or a subclass) as a parameter.
> > >
> >
> > Okay, I''ll just move what I was going to place in post_into
into another
> > method and call that from the block...
> >
>
>
> I''m giving serious thought to changing how this works because it
seems to
> cause to serious inconvenience.
>
> (Side point: it''s important for protocol handlers to be
"sense-neutral"
> whenever possible, meaning that the same user code can be used either in a
> network server or network client without change.)
>
> Originally, the EventMachine::Connection class was "buried"
(called only
> by the reactor, never by user code), and protocol handlers were developed
by
> writing Ruby Modules. Now, a lot of people subclass EM::Connection (often
> because they need to do initializations and they want the other benefits of
> writing a class).
>
> I''m always troubled by the fact that you *must* remember to call
super in
> your initialize method if you subclass EM::Connection. That''s one
thing I''d
> like to change.
>
> EM::Connection#post_init is currently called from *inside* the base class
> constructor, but it could probably be moved outside of it and called
> afterward. That would eliminate confusion about the behavior of #post_init
> with respect to the positioning of the super call inside subclassed
> constructors.
>
> The major limitation of both the constructor (both base class and
> subclassed) and of #post_init is that they''re called by the
reactor *with no
> parameters.*
>
> As long as that remains true, there will be a need for the block that is
> passed to EM#start_server. It takes a parameter which is the newly-created
> object, on which you can call any method, and it can be super-useful
because
> it''s a closure in the context where #start_server is called. It
still seems
> to me that the most logical place to call the block is after #post_init is
> called. Given all that, do we really need #post_init?
>
> #post_init was originally invented because of protocol handlers that are
> Modules rather than subclasses of EM::Connection. There was no way to
> initialize these without #post_init. (Passing blocks to #start_server was
> invented later.) I''m not proposing to eliminate #post_init, but
it''s
> probably a good idea to avoid it in new code.
>
> Thoughts?
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
I always did feel that post_init felt a bit, well, hackish. It''s
understandable to have a connection callback if the user is putting in a
module, but I, like many others, prefer dealing directly with classes, so
the logical thing would then to have new connection information come in with
the initializer.

How much work would it be to keep both around? When using a Module, fire off
the post_init call, otherwise just #new and let the user do what he pleases?

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071022/6ad1cd99/attachment-0001.html

On 10/22/07, Jason Roelofs <jameskilton at gmail.com> wrote:

I always did feel that post_init felt a bit, well, hackish.
It''s
> understandable to have a connection callback if the user is putting in a
> module, but I, like many others, prefer dealing directly with classes, so
> the logical thing would then to have new connection information come in
with
> the initializer.
>
> How much work would it be to keep both around? When using a Module, fire
> off the post_init call, otherwise just #new and let the user do what he
> pleases?


The problem is  that, with a TCP client, the reactor calls
EM::Connection#new, not the user code. You can''t really pass parameters
to
it. I''m open to adding a class method of EM::Connection that would
allow
specific parameters to be passed to new instances.

Syntax suggestions?

Jason, I still have to get you the coordinates to build a Trac at
rubyeventmachine.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071022/917352ea/attachment.html

On 10/22/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> The problem is  that, with a TCP client, the reactor calls
> EM::Connection#new, not the user code. You can''t really pass
parameters to
> it. I''m open to adding a class method of EM::Connection that would
allow
> specific parameters to be passed to new instances.
>
That''s exactly what I''m trying to accomplish: initializing the
new instance
with variables available in the scope of where #start_server is called.

As things stand it seems like .new is leaving my objects in a
half-initialized state which is completed when #start_server yields to the
block where I can pass in the variables available in the scope of where
#start_server is called.

Ideally I''d like to see something like EM::Connection''s
initialize yielding
self to the block passed to #start_server.  This is similar to what
ActiveRecord does to let you do things like define associations before AR::
B.new ever returns.

--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071025/75a42fab/attachment.html

On 10/25/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> On 10/22/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
>
> > The problem is  that, with a TCP client, the reactor calls
> > EM::Connection#new, not the user code. You can''t really pass
parameters to
> > it. I''m open to adding a class method of EM::Connection that
would allow
> > specific parameters to be passed to new instances.
> >
>
> That''s exactly what I''m trying to accomplish:
initializing the new
> instance with variables available in the scope of where #start_server is
> called.
>
> As things stand it seems like .new is leaving my objects in a
> half-initialized state which is completed when #start_server yields to the
> block where I can pass in the variables available in the scope of where
> #start_server is called.
>
> Ideally I''d like to see something like EM::Connection''s
initialize
> yielding self to the block passed to #start_server.  This is similar to
what
> ActiveRecord does to let you do things like define associations before AR::
> B.new ever returns.
>

EM::Connection''s initialize doesn''t yield self, however, the
code that calls
EM::Connection.new yields the newly-created Connection object to the block
passed to #start_server. So it amounts to the same thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071026/8753c24f/attachment.html

On 10/22/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
>
> I''m always troubled by the fact that you *must* remember to call
super in
> your initialize method if you subclass EM::Connection. That''s one
thing I''d
> like to change.
>
Here''s a way to avoid that (courtesy Ara Howard):

class Parent
  def self.new *a, &b
    allocate.instance_eval {
      :this_avoids_super
      initialize *a, &b
      self
    }
  end
end

class Child
  def initialize *a, &b
  end
end


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
720-227-0129 ext. 202
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071026/ddd4da1f/attachment.html

On 10/26/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> On 10/22/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> >
> > I''m always troubled by the fact that you *must* remember to
call super
> > in your initialize method if you subclass EM::Connection.
That''s one thing
> > I''d like to change.
> >
>
> Here''s a way to avoid that (courtesy Ara Howard):
>
> class Parent
>   def self.new *a, &b
>     allocate.instance_eval {
>       :this_avoids_super
>       initialize *a, &b
>       self
>     }
>   end
> end
>
> class Child
>   def initialize *a, &b
>   end
> end
>

What happens if you use that, and you ALSO call super in the subclass
constructor? (As plenty of existing code does.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071026/01fb2a04/attachment.html

Since initialize is never declared in the superclass, calling super from the
subclass''s initialize does nothing.  It''d be backwards
compatible.

On 10/26/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
>
> On 10/26/07, Tony Arcieri <tony at clickcaster.com> wrote:
> >
> > On 10/22/07, Francis Cianfrocca <garbagecat10 at gmail.com >
wrote:
> > >
> > > I''m always troubled by the fact that you *must* remember
to call super
> > > in your initialize method if you subclass EM::Connection.
That''s one thing
> > > I''d like to change.
> > >
> >
> > Here''s a way to avoid that (courtesy Ara Howard):
> >
> > class Parent
> >   def self.new *a, &b
> >     allocate.instance_eval {
> >       :this_avoids_super
> >       initialize *a, &b
> >       self
> >     }
> >   end
> > end
> >
> > class Child
> >   def initialize *a, &b
> >   end
> > end
> >
>
>
> What happens if you use that, and you ALSO call super in the subclass
> constructor? (As plenty of existing code does.)
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
720-227-0129 ext. 202
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071026/eb2efc9d/attachment.html

On 10/26/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
>
> On 10/26/07, Tony Arcieri <tony at clickcaster.com> wrote:
> >
> > On 10/22/07, Francis Cianfrocca <garbagecat10 at gmail.com >
wrote:
> > >
> > > I''m always troubled by the fact that you *must* remember
to call super
> > > in your initialize method if you subclass EM::Connection.
That''s one thing
> > > I''d like to change.
> > >
> >
> > Here''s a way to avoid that (courtesy Ara Howard):
> >
> > class Parent
> >   def self.new *a, &b
> >     allocate.instance_eval {
> >       :this_avoids_super
> >       initialize *a, &b
> >       self
> >     }
> >   end
> > end
> >
> > class Child
> >   def initialize *a, &b
> >   end
> > end
> >
>
Tried the code and it doesn''t call the base class constructor. Maybe I
did
something wrong. (I did add < Parent to your declaration of class Child)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071026/018c2ab1/attachment.html

Whoops... yes Child should be a subclass of Parent :)

Put what would ordinarily go in Parent''s initialize inside of the
instance
eval block, or rename the base class''s initialize and call that method
from
inside the instance eval block

On 10/26/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
>
> On 10/26/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> >
> > On 10/26/07, Tony Arcieri <tony at clickcaster.com> wrote:
> > >
> > > On 10/22/07, Francis Cianfrocca <garbagecat10 at gmail.com
> wrote:
> > > >
> > > > I''m always troubled by the fact that you *must*
remember to call
> > > > super in your initialize method if you subclass
EM::Connection. That''s one
> > > > thing I''d like to change.
> > > >
> > >
> > > Here''s a way to avoid that (courtesy Ara Howard):
> > >
> > > class Parent
> > >   def self.new *a, &b
> > >     allocate.instance_eval {
> > >       :this_avoids_super
> > >       initialize *a, &b
> > >       self
> > >     }
> > >   end
> > > end
> > >
> > > class Child
> > >   def initialize *a, &b
> > >   end
> > > end
> > >
> >
> Tried the code and it doesn''t call the base class constructor.
Maybe I did
> something wrong. (I did add < Parent to your declaration of class Child)
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
720-227-0129 ext. 202
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071026/b0e7073e/attachment-0001.html

In the end this seems like it''s all much ado about arguments that could
just
get passed straight into initialize.  The problem right now is that
Connection#initialize is trying to shuffle around some internal arguments,
which is getting in the way of arguments that are getting passed to its
subclasses.

If you implemented the above hack you could do the following:

http://pastie.caboo.se/112525

The above should be fully backwards compatible with the existing API and
should just let you pass whatever arguments you want passed to the
subclass''s #initialize directly to start_server.  That way you could
process
them directly in your subclass''s #initialize, configure your instance
variables there, and avoid calling super (without breaking legacy code that
does call super).

Does that seem like a good solution?

On 10/26/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> Whoops... yes Child should be a subclass of Parent :)
>
> Put what would ordinarily go in Parent''s initialize inside of the
instance
> eval block, or rename the base class''s initialize and call that
method from
> inside the instance eval block
>
> On 10/26/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
>
> > On 10/26/07, Francis Cianfrocca <garbagecat10 at gmail.com >
wrote:
> > >
> > > On 10/26/07, Tony Arcieri <tony at clickcaster.com> wrote:
> > > >
> > > > On 10/22/07, Francis Cianfrocca <garbagecat10 at
gmail.com > wrote:
> > > > >
> > > > > I''m always troubled by the fact that you
*must* remember to call
> > > > > super in your initialize method if you subclass
EM::Connection. That''s one
> > > > > thing I''d like to change.
> > > > >
> > > >
> > > > Here''s a way to avoid that (courtesy Ara Howard):
> > > >
> > > > class Parent
> > > >   def self.new *a, &b
> > > >     allocate.instance_eval {
> > > >       :this_avoids_super
> > > >       initialize *a, &b
> > > >       self
> > > >     }
> > > >   end
> > > > end
> > > >
> > > > class Child
> > > >   def initialize *a, &b
> > > >   end
> > > > end
> > > >
> > >
> > Tried the code and it doesn''t call the base class
constructor. Maybe I
> > did something wrong. (I did add < Parent to your declaration of
class Child)
> >
> >
> > _______________________________________________
> > Eventmachine-talk mailing list
> > Eventmachine-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> >
>
>
>
> --
> Tony Arcieri
> ClickCaster, Inc.
> tony at clickcaster.com
> 720-227-0129 ext. 202
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
720-227-0129 ext. 202
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071030/67b96a83/attachment-0001.html

On 10/30/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> In the end this seems like it''s all much ado about arguments that
could
> just get passed straight into initialize.  The problem right now is that
> Connection#initialize is trying to shuffle around some internal arguments,
> which is getting in the way of arguments that are getting passed to its
> subclasses.
>
> If you implemented the above hack you could do the following:
>
> http://pastie.caboo.se/112525
>
> The above should be fully backwards compatible with the existing API and
> should just let you pass whatever arguments you want passed to the
> subclass''s #initialize directly to start_server.  That way you
could process
> them directly in your subclass''s #initialize, configure your
instance
> variables there, and avoid calling super (without breaking legacy code that
> does call super).
>
> Does that seem like a good solution?


I like it. Can you check it in? After we''re sure it doesn''t
regress, we''ll
add a line to ChangeLog.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071030/c16cbcbe/attachment.html

Okay, done.  Appears to be passing the existing tests, at least from my
side.

On 10/30/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
>
> On 10/30/07, Tony Arcieri <tony at clickcaster.com> wrote:
> >
> > In the end this seems like it''s all much ado about arguments
that could
> > just get passed straight into initialize.  The problem right now is
that
> > Connection#initialize is trying to shuffle around some internal
arguments,
> > which is getting in the way of arguments that are getting passed to
its
> > subclasses.
> >
> > If you implemented the above hack you could do the following:
> >
> > http://pastie.caboo.se/112525
> >
> > The above should be fully backwards compatible with the existing API
and
> > should just let you pass whatever arguments you want passed to the
> > subclass''s #initialize directly to start_server.  That way
you could process
> > them directly in your subclass''s #initialize, configure your
instance
> > variables there, and avoid calling super (without breaking legacy code
that
> > does call super).
> >
> > Does that seem like a good solution?
>
>
>
> I like it. Can you check it in? After we''re sure it
doesn''t regress, we''ll
> add a line to ChangeLog.
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
720-227-0129 ext. 202
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071030/c49c2b4a/attachment.html

It''d be nice to add some sort of arity checking to ensure that the
number of
arguments passed to start_server will match the number initialize expects.
Otherwise defining initialize in a subclass that takes a different number of
arguments than what was passed to start_server will cause an error in EM::
Connection.new when it causes initialize.

I''d like to check klass.instance_method(:initialize).arity in the
start_server methods and compare that against args.size, but I don''t
know
what I should do if there''s a mismatch.  Should I raise an exception?

On 10/30/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> Okay, done.  Appears to be passing the existing tests, at least from my
> side.
>
> On 10/30/07, Francis Cianfrocca < garbagecat10 at gmail.com> wrote:
>
> > On 10/30/07, Tony Arcieri <tony at clickcaster.com> wrote:
> > >
> > > In the end this seems like it''s all much ado about
arguments that
> > > could just get passed straight into initialize.  The problem
right now is
> > > that Connection#initialize is trying to shuffle around some
internal
> > > arguments, which is getting in the way of arguments that are
getting passed
> > > to its subclasses.
> > >
> > > If you implemented the above hack you could do the following:
> > >
> > > http://pastie.caboo.se/112525
> > >
> > > The above should be fully backwards compatible with the existing
API
> > > and should just let you pass whatever arguments you want passed
to the
> > > subclass''s #initialize directly to start_server.  That
way you could process
> > > them directly in your subclass''s #initialize, configure
your instance
> > > variables there, and avoid calling super (without breaking legacy
code that
> > > does call super).
> > >
> > > Does that seem like a good solution?
> >
> >
> >
> > I like it. Can you check it in? After we''re sure it
doesn''t regress,
> > we''ll add a line to ChangeLog.
> >
> >
> > _______________________________________________
> > Eventmachine-talk mailing list
> > Eventmachine-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> >
>
>
>
> --
> Tony Arcieri
> ClickCaster, Inc.
> tony at clickcaster.com
> 720-227-0129 ext. 202
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
720-227-0129 ext. 202
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071030/a4aeabce/attachment-0001.html

I went ahead and added an arity check in start_server which raises a
Ruby-like ArgumentError.  It looks something like this:

wrong number of arguments for MyConnection#initialize (3 for 2)
(ArgumentError)

Otherwise, if the arity of #initialize doesn''t thunk with the arguments
passed to start_server, you don''t find out until a connection is
accepted
and #initialize is called.  This catches it right away.

Let me know if you think this is confusing and/or not the correct approach.

On 10/30/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> It''d be nice to add some sort of arity checking to ensure that the
number
> of arguments passed to start_server will match the number initialize
> expects.  Otherwise defining initialize in a subclass that takes a
different
> number of arguments than what was passed to start_server will cause an
error
> in EM:: Connection.new when it causes initialize.
>
> I''d like to check klass.instance_method(:initialize).arity in the
> start_server methods and compare that against args.size, but I
don''t know
> what I should do if there''s a mismatch.  Should I raise an
exception?
>
> On 10/30/07, Tony Arcieri <tony at clickcaster.com> wrote:
> >
> > Okay, done.  Appears to be passing the existing tests, at least from
my
> > side.
> >
> > On 10/30/07, Francis Cianfrocca < garbagecat10 at gmail.com>
wrote:
> >
> > > On 10/30/07, Tony Arcieri <tony at clickcaster.com> wrote:
> > > >
> > > > In the end this seems like it''s all much ado about
arguments that
> > > > could just get passed straight into initialize.  The problem
right now is
> > > > that Connection#initialize is trying to shuffle around some
internal
> > > > arguments, which is getting in the way of arguments that are
getting passed
> > > > to its subclasses.
> > > >
> > > > If you implemented the above hack you could do the
following:
> > > >
> > > > http://pastie.caboo.se/112525
> > > >
> > > > The above should be fully backwards compatible with the
existing API
> > > > and should just let you pass whatever arguments you want
passed to the
> > > > subclass''s #initialize directly to start_server. 
That way you could process
> > > > them directly in your subclass''s #initialize,
configure your instance
> > > > variables there, and avoid calling super (without breaking
legacy code that
> > > > does call super).
> > > >
> > > > Does that seem like a good solution?
> > >
> > >
> > >
> > > I like it. Can you check it in? After we''re sure it
doesn''t regress,
> > > we''ll add a line to ChangeLog.
> > >
> > >
> > > _______________________________________________
> > > Eventmachine-talk mailing list
> > > Eventmachine-talk at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> > >
> >
> >
> >
> > --
> > Tony Arcieri
> > ClickCaster, Inc.
> > tony at clickcaster.com
> > 720-227-0129 ext. 202
> >
>
>
>
> --
> Tony Arcieri
> ClickCaster, Inc.
> tony at clickcaster.com
> 720-227-0129 ext. 202
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071031/335afd37/attachment.html

On 10/31/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> I went ahead and added an arity check in start_server which raises a
> Ruby-like ArgumentError.  It looks something like this:
>
> wrong number of arguments for MyConnection#initialize (3 for 2)
> (ArgumentError)
>
> Otherwise, if the arity of #initialize doesn''t thunk with the
arguments
> passed to start_server, you don''t find out until a connection is
accepted
> and #initialize is called.  This catches it right away.
>
> Let me know if you think this is confusing and/or not the correct
> approach.


Thanks, Tony- been a little busy, will test and report later on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071031/81ac0071/attachment.html

It''d be nice to do the same thing for EventMachine::connect, if only
for
consistency''s sake

On 10/31/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
>
> On 10/31/07, Tony Arcieri <tony at clickcaster.com> wrote:
> >
> > I went ahead and added an arity check in start_server which raises a
> > Ruby-like ArgumentError.  It looks something like this:
> >
> > wrong number of arguments for MyConnection#initialize (3 for 2)
> > (ArgumentError)
> >
> > Otherwise, if the arity of #initialize doesn''t thunk with the
arguments
> > passed to start_server, you don''t find out until a connection
is accepted
> > and #initialize is called.  This catches it right away.
> >
> > Let me know if you think this is confusing and/or not the correct
> > approach.
>
>
>
> Thanks, Tony- been a little busy, will test and report later on.
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071106/482d3a56/attachment.html

On 11/6/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> It''d be nice to do the same thing for EventMachine::connect, if
only for
> consistency''s sake

Agreed. Want to give it a shot?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071106/befe1309/attachment.html

Well, that was fairly simple as EventMachine::connect (and friends) make a
new object inside that actual method.

Initial cut is checked in and all tests are passing.

I''ll try to add an arity check next.

On 11/6/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
>
> On 11/6/07, Tony Arcieri <tony at clickcaster.com> wrote:
> >
> > It''d be nice to do the same thing for EventMachine::connect,
if only for
> > consistency''s sake
>
>
> Agreed. Want to give it a shot?
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071106/ae9a1a19/attachment.html

I committed the arity check, and all tests are passing.

An arity mismatch now raises:

eventmachine-0.9.0/lib/eventmachine.rb:638:in `connect'': wrong number
of
arguments for MyConnection#initialize (3 for 2) (ArgumentError)

There''s now 5 of these arity checks duplicated throughout
eventmachine.rb.
It''d be nice to DRY them out... possibly in a protected/private class
method
of EventMachine.

On 11/6/07, Tony Arcieri <tony at clickcaster.com>
wrote:
>
> Well, that was fairly simple as EventMachine::connect (and friends) make a
> new object inside that actual method.
>
> Initial cut is checked in and all tests are passing.
>
> I''ll try to add an arity check next.
>
> On 11/6/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
>
> > On 11/6/07, Tony Arcieri <tony at clickcaster.com> wrote:
> > >
> > > It''d be nice to do the same thing for
EventMachine::connect, if only
> > > for consistency''s sake
> >
> >
> > Agreed. Want to give it a shot?
> >
> >
> > _______________________________________________
> > Eventmachine-talk mailing list
> > Eventmachine-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> >
>
>
>
> --
> Tony Arcieri
> ClickCaster, Inc.
> tony at clickcaster.com
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071106/e990541d/attachment.html