Re: Adding Glib::IO to the released modules

[Emmanuele Bassi <ebassi gmail com>]

Hi Torsten;

On 23 June 2017 at 10:36, Torsten Schoenfeld <kaffeetisch gmx de> wrote:
> Hi Emmanuele!
>
> On 20.06.2017 12:35, Emmanuele Bassi wrote:
> > > We discussed this some time ago on the list. But I think, there was nobody, who could maintain the 
> > > Glib::IO module. Jeremy Volkening and I worked a little bit on the module. But we had not enough time to 
> > > make it release-ready. And in my case, I don't have the competence to really maintain such a complex 
> > > module!
> >
> > It's been a while since I maintained a Perl module, but I'd be happy
> > to work on it.
>
> Please feel free to go ahead then.  For a first release, I think the
> documentation placeholders ("XXX" in README and lib/Glib/IO.pm) should
> be handled.  When you do this, please also update all the copyright and
> author statements, as you will have written most of the module by then. :-)

Done. :-)

> Maybe Brian can be coaxed to handle the actual CPAN and SourceForge
> release process?

That would be most appreciated.

> A separate question is whether Gtk3 should automatically load Glib::IO,
> which pulls in the rather large GIO API.  On my machine, adding "use
> Glib::IO" to Gtk3 increases the load time from roughly 0.068 s to 0.084
> s (measured with "dumbbench -- perl -MGtk3 -e0"), i.e., a slow-down of
> about 24 %.  Is this significant enough to warrant the inconvenience of
> having to manually load Glib::IO when needed?

The slowdown is kind of a one-off, and if you're writing a GUI, adding
20 milliseconds to startup time is not going to be a massive pain.

Nevertheless, I think it's perfectly fine to ask Perl developers to
load Glib::IO explicitly. It doesn't seem to be a problem for Python
and JavaScript developers using their own introspection-based
machinery, after all.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]