Re: RFC: split gtk2-perl-xs

[Jörn Reder <joern zyn de>]

goran kirra net wrote:

> 2. G::<namespace>: I think this would be hard to get accepted in CPAN since what G::
> reference
>    hardly is clear to people not into Gtk+/Gnome. Either we should change it to GLib:: or
>    just move it into Gtk2:: since the functionality in GObject et al is not especially useful
>    to perlprogrammers outside to Gtk+ context.

I admit, that G:: could be hard to be accepted in CPAN, but that's not a
reason not to question this.

> From the Glib and Gtk2 programmer's point of view the G:: namespace is 
very convenient and reasonable (the mapping from C to Perl names is 
nearly perfect). So which reasons really speak against the G:: 
namespace? Ok it's short, but what's the problem with short namespaces?
Ok, there are *very* few one letter namespaces (for Perl 5 we have 26 
;), some of them are allocated already (e.g. B::). Sure, with limited 
namespace names it's more likely to get a conflict. But which module 
needs G:: also? And even if there would be another candidate: there are
many modules for the same purpose out there, and the "best" name was 
allocated by the one who was first, the others need to call it 
different. So I can't see any non-academic arguments against G::. I 
think it must be easy to use for the people who need it, and that are 
Gtk2 developers, not an abstract instance like CPAN.

It's correct not to name another HTML-Parser module 'HTMLParserXY::'. 
Better one should name it under the already existent HTML:: namespace. 
But here a completely new class of modules is created, so in my opinion
it's Ok to allocate a new toplevel namespace for it.

But if we decide not to use G::, I'd vote against Gtk2::G, because I'm 
with Ross here: having the child under the parent's namespace is bad. 
And if you want to use Glib mappings without Gtk2, it's strange to "use
Gtk2::G" for them. So if not G:: I'd vote for Glib::.

Regards,

Joern

-- 
LINUX - Linux Is Not gnU linuX