Re: namespaces

[Jörn Reder <joern zyn de>]

"muppet" wrote:

> in case you hadn't noticed, i decided in new-gtk2-perl to break the glib stuff
> out from under the Gtk2 namespace, so show the separation of concepts from Gtk
> and its base library, and so to relieve users of GObject/GLib-only-based
> extensions from needing to load all of Gtk2 to get to the base functions
> (enum/flag conversion, GObject/GBoxed handling, GSignal, etc etc).

The namespace decision is independent from packaging of Gtk2 and GObject
together (or not doing it). Assuming Gtk2::GObject is the Perl package 
name for GObject you just can

  use Gtk2::GObject;

without loading, using or knowing Gtk2 at all ;)

> - it has been pointed out that G is not a neighbor-friendly namespace.  i
> don't think that it stomps on anything, but it's only one letter.  then again,
> i don't like GObject as a namespace because this module wraps GLib's main loop
> and all other sorts of stuff.  GLib is a suggestion that sounded reasonable,
> but i like G for aesthetic reasons, and the fact that it makes the names map
> very very cleanly from C.  who wants to convince me to change it?  who wants
> to argue to keep it?  (good arguments with examples, please)

> From the aesthetic point of view I like the G package very much. In 
particular because it can be used to create applications, which only 
need the corresponding GLib functionality (no Gtk2, Gdk or whatever), a
separate toplevel package makes sense. If the API is stabilized, all 
those modules could be released as seperate packages to CPAN (where Gtk2
depends on G and stuff), so they are really indepedent from each other.

That's the first side of the story, but...

I'm not sure if single letter namespaces are reserved (think of the B 
package, which is very specific and part of Perl's core). I checked the
module list documentation and couldn't find a hint, that single letter 
namespaces are explicitely forbidden (although it says, it's not 
recommended to use too short and abstract names, and not to introduce 
new toplevel namespaces ;) So, let's say, it's Ok to have single letter
packages, and yes: it makes sense to introduce some new toplevel 
packages ;)

The documentation on www.gtk.org names the whole stuff "Gtk2-2.0 
platform", and indeed, everything belongs very tight together (at least
from the Gtk2 point of view, which depends on all libs of this 
"platform"). To make this transparent, a namespace which prefixes all 
modules with Gtk2 seems to be reasonable:

  Gtk2
  Gtk2::Widget
  Gtk2::G::Object
  Gtk2::G::Timeout

similar to Gtk1, where the Gdk mapping is called Gtk::Gdk.

> - when creating a GtkListStore in C, you supply a list of GTypes specifying
> the types of the columns.  i have changed this to a list of package names in
> perl.  this means i have the G module automatically registering types to
> packages such as G::String, G::Uint, G::Boolean, etc.  anybody have any better
> ideas?  how about simpler names like 'string', 'uint', 'boolean' for the
> fundamental types, and a package name for anything classes?

I think mapping package names to these types is a good solution. It's 
clean and correspondents directly to the implementation, no "internal 
magic mapping" from "uint" to something different. But, taking my 
paragraph above into account, this looks really ugly:

  Gtk2::G::String

A generic String class inside the Gtk2 package? *shiver* ;)

> - i mapped g_timeout_add to G::Timeout->add, g_idle_add to G::Idle->add,
> g_io_add_watch to G::IO->add_watch, and g_source_remove to G::Source->remove. 
> any better ideas?

To turn the discussion around: no ;) From the Perl application 
programmers point of view, the package names you suggested are 
intuitional and easy to understand and to learn (what else counts? ;) 
They map straight to the corresponding C packages. The only, what 
probably slightly conflicts, are the general Perl namespacing rules, 
depending on how one interpretes them. In fact, the names doesn't 
conflict with actually registered Perl modules. CPAN namespace 
reserveration follows the principle first-come-first-serve. Who is 
first? ;)

Regards,

Joern

-- 
Joern Reder
supporting:   http://www.zyn.de/
unbelievable: http://www.exit1.org/
CPAN:         http://www.perl.com/CPAN/modules/by-authors/id/J/JR/JRED