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.
>> It's not too troublesome to add this to
>> my codes:
>
>I don't think it would be too much of an issue if the require was removed
>from the AUTOLOAD.
>
>> require $_ for qw(Event::io Event::timer); # untested
>
>I am sure it is untested, as it will not work :-(
>
>Perl only does the package->file name translation if the
>argument to require is constant.
>
>You could consider adding an Event::Type package (ala Tk::widget)
>so you can type
>
> use Event::Type qw(io idle);
The short-hand-for-explicit-require that is Tk::widget does
not have any drawbacks as far as I am aware.
>
>Or you could do something with import in Event::Watcher.
>
>
>Of course you should also consider if Event->io should use AUTOLOAD or
>if Event::io should just call a register method to create the sub, thus
>doing away with AUTOLOAD all together.
Tk with explcit require does the later - i.e. Tk/Foo.pm
drops a Tk::Widget::Foo into the name space (via an inherited 'Construct'
method but that is detail).
--
Nick Ing-Simmons
