Re: Standalone Pango, take two

[muppet <scott asofyet org>]

On Nov 2, 2008, at 1:14 PM, Sergei Steshenko wrote:

> --- On Sun, 11/2/08, Torsten Schoenfeld <kaffeetisch gmx de> wrote:
>
> > Sergei Steshenko wrote:
> > > I think the safest approach is to export/map
> > _nothing_.
> > > If one needs method/data, he/she should explicitly
> > prefix it with
> > > package name.
> >
> > I think you're confusing something here.  We are not
> > talking about exporting symbols into the user's
> > namespace.  Gtk2 never did that (if not asked for it), Pango
> > will not do it, and the compatibility layer will not do it
> > either.  We are talking about creating aliases in
> > Gtk2::Pango for the symbols in Pango.
> >
> > -Torsten
>
> Then what is export exactly ?
>
> Isn't it populating one package namespace with symbols from another  
> package ?

Yes, that's what exporting is.  That's not at all what we're discussing.

We initially had the pango library wrapped in the namespace  
Gtk2::Pango, because we thought, naively, "who would ever want to use  
pango without gtk+?"  Well, there are those who do.  Now we have pango  
wrapped in the namespace Pango, but we still need the existing code to  
work.  Hence, the discussion is about making sure that references to  
Gtk2::Pango::foo will map correctly to Pango::foo.

The "yellow wire" trick was a brute-force mapping of everything in the  
Pango namespace to the Gtk2::Pango namespace --- two names for each  
symbol, basically.  We're trying to determine if there's a better way.

The only exports involved here are the PANGO_FOO constants from the  
actual Gtk2::Pango module, which was imported by the user only if  
needed.


--
Well done, Android.  Aperture Science reminds you that Android Hell is  
a real place, and you will be sent there at the first sign of defiance.
   -- GlaDOS