Return-Path: Mailing-List: contact dev-help@perl.apache.org; run by ezmlm Delivered-To: mailing list dev@perl.apache.org Received: (qmail 8997 invoked from network); 14 Feb 2001 22:06:30 -0000 Received: from sfo-gw.covalent.net (HELO mako.covalent.net) (207.44.198.62) by h31.sny.collab.net with SMTP; 14 Feb 2001 22:06:30 -0000 Received: from localhost (dougm@localhost) by mako.covalent.net (8.11.0/8.11.0) with ESMTP id f1EM5vg26741; Wed, 14 Feb 2001 14:05:57 -0800 X-Authentication-Warning: mako.covalent.net: dougm owned process doing -bs Date: Wed, 14 Feb 2001 14:05:56 -0800 (PST) From: Doug MacEachern To: Geoffrey Young cc: "'dev@perl.apache.org'" Subject: Re: Apache->can() bug? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Thu, 8 Feb 2001, Geoffrey Young wrote: > hi guys... > > oops, I forgot to cross-post my modperl@ report here... > > looks like Apache->can('push_handlers') returns true even if > PERL_STACKED_HANDLERS=0 at build time (at least with CVS) > > I suppose that at some point this wasn't the case, since Apache::DBI seems > to have purposely coded against can() actually, Apache::DBI is supposed to call Apache->can_push_handlers(). i originally submitted the patch to edmund for connect_on_init that used can_push_handlers(), i guess he assumed Apache->can('push_handlers') would do the same. Apache::can_push_handlers was added long before UNIVERSAL::can existed in the Perl core. it was also before xsubpp could properly support #ifdef in .xs code. so i guess the right thing todo for modern Perls would be throw away Apache::can_push_handlers and #ifdef PERL_STACKED_HANDLERS around mod_perl_push_handlers() in Apache.xs i doubt anything besides Apache::DBI is using Apache::can_push_handlers, don't think its documented either.