>>>>> "JNP" == Joshua N Pritikin <[EMAIL PROTECTED]> writes:
JNP> On Thu, Feb 03, 2000 at 04:19:49PM +0000, [EMAIL PROTECTED] wrote:
>> Graham Barr <[EMAIL PROTECTED]> writes:
>> >> >
>> >> > well that can be fixed easily. i am only in development. how many users
>> >> > of event.pm are there? it is classified as beta code as well.
>> >> >
>> >> > on the other hand, most event watchers are created at startup. so the
>> >> > chances of a long wait before a dynamic load triggers a compile error
>> >> > are slim. and there are a lot fewer of them than tk things to load so it
>> >> > is easier to manage and keep the compiler bugs out.
>> >>
>> >> Nick, are you satisfied with Uri's comments? We *can* change Event if
>> >> folks feel strongly about it.
>>
>> I would recomment removing the implied require.
JNP> Done.
JNP> Everyone, thanks for your input. I grok the need for B::* to see
JNP> everything at compile time.
sorry to get in on the tail of this but how is this for a solution?
in Event.pm have stub subs like this which only load the real one and
overload the sub's typeglob.
(untested but i am sure graham can fix it :-)
sub Event::io {
require 'Event/io.pm' ;
*Event::io = \&Event::io::new ;
goto &Event::io ;
}
how crazy/workable is that?
other than that i don't care how the code gets loaded and in fact i
wouldn't mind if all of Event.pm were loaded in one shot as i expect to
use most of it and startup time is generally not an issue with my needs
right now. stem is meant to be a long lived system and startup time is
ignored. others may want faster startup where you load code as needed.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
