On Wed, Nov 03, 2004 at 12:08:08AM +0900, trans.  (T. Onoma) wrote:
> | That sentence doesn't make much sense to me - can you define what you mean
> | by "modifying .. to be a Singleton class rather than a regular class" ??
> 
> Ah yes, the old name confusion. Sorry. I'm _not_ referring to Virtual class 
> (or Instance class), which is also called singleton. That's different. (BTW 
> we really need to get onto this new naming convention to prevent this 
> confusion! Yes?) I'm referring to the other kind where by only one instance 
> of a class can exist. See Singleton module for more info on that.

OK, the 'Singleton pattern'. Always seemed rather pointless to me; if
there's only ever going to be one CGI instance, then you might as well make
all the methods class methods of CGI itself, and use class instance
variables.

> So if I make CGI singleton, then only one instance of it ever exists 
> --presumably even between http requests. Thus an increase in performance. But 
> like I said I'm not perfectly clear about how it all works, and how FCGI 
> might fit in.

Well, it seems to me that each request ought to create a different CGI
object, for the simple reason that each HTTP request has a different set of
parameters - and it's the CGI object that represents them.

I suppose you could 're-use' the previous CGI object, by resetting its
instance variables to the new request, but that's not a very Rubyesque way
of doing things (IMO).

It would be better, I think, to make the object creation faster by not doing
all those slow eval def's each time. For example, if you want to include the
CGI::Html3 module you could first check if it exists, and if it doesn't then
define it (in the slow eval way if that's tidier). Subsequent requests can
just do 'extend CGI::Html3' which is fast. e.g.

  unless defined? Html3
    module Html3
      .. define static methods
    end
    .. define methods dynamically using eval
  end
  extend Html3

Regards,

Brian.