PangoCairoFontMap is a subtype of PangoFontMap.  All pango_*_font_map_* functions that return a fontmap return it as PangoFontMap *, while all those getting a fontmap parameter take a specialized one (except for a few, like pango_win32_font_map_get_font_cache.)  I don't think we are going to change this at this time.

> PangoCairoFontMap is a subtype of PangoFontMap

Are you saying that PangoFontMap implements the PangoCairoFontMap interface? I can't actually find pango_font_map_get_type()'s implementation, so I can't tell.

Sorry, my bad.

PangoFontMap is the base type, and PangoCairoFontMap is an interface.  The actual type returned is one of PangoCairoFcFontMap, PangoCairoWin32FontMap, or PangoCairoATSUIFontMap, and they all extend PangoFontMap, and implement PangoCairoFontMap.

Thanks. Still I don't see a need to break the usual pattern for _new functions. This is going to really confuse some bindings.

Is it just because PangoFontMap has more useful API than PangoCairoFontMap and you want to save people from having to cast it? Maybe you could just make it part of the PangoFontMap API. That doesn't have a _new() function yet and it doesn't seem to be instantiated directly by users of Pango yet.

And am I ever meant to use the PangoCairoFontMap interface on that PangoFontMap*? If PangoFontMap doesn't implement from PangoCairoFontMap then there's no way that most languages could cast from PangoFontMap to PangoCairoFontMap.

I'd have to cast up to, for instance, PangoCairoFcFontMap first and then cast back down to PangoCairoFontMap.

I can correct this function in the C++ API, but I'd like to understand your intent.

Actually, most languages are a lot more flexible about casting than
C++... though certain less ornate in other ways...

I can never quite keep the C++ rules straight for more than 5 minutes,
but you *might* be able to represent the situation as:

                    PangoFontMap
                  /           \
         PangoFcFontMap    PangoCairoFontMap
                  \            /
                PangoCairoFcFontMap

Since we do have:

 g_type_interface_add_prerequisite (cairo_font_map_type, PANGO_TYPE_FONT_MAP);

if you can avoid diamond-shaped-inheritance traps.

But in most languages, interfaces can't inherit from concrete classes
so we have simply:

        PangoFontMap
                \
         PangoFcFontMap    PangoCairoFontMap
                  \            /
                PangoCairoFcFontMap

That being the case, it made more sense to me to make create_font_map()
return PangoFontMap than PangoCairoFontMap, since typical usage of the
result will be as a PangoFontMap not as a PangoCairoFontMap.

Thinking about it, I'm going to have this casting problem with either return type,  because I'll need to cast to the other type some time. This hierarchy is not impossible in C++, but it would be avoided because it's not polymorphic for both base classes. I'll deal with it, maybe by adding some special methods to hide the awkward casting.

Are regular PangoFontMaps ever instantiated outside of Pango itself, or can I consider this as the only way to instantiate a PangoFontMap?

Are there now any PangoFontMap instances that do not implement PangoCairoFontMap? If not, it might make sense to just make PangoFontMap implement it.

There are various different PangoFontMap subtypes: PangoFT2FontMap, PangoXftFontMap, PangoFcFontMap, PangoWin32FontMap, PangoATSUIFontMap, none of which implement PangoCairoFontMap.  There are then PangoCairoFcFontMap, PangoCairoWin32FontMap, and PangoCairoATSUIFontMap that extend their respective non-Cairo fontmap and implement the PangoCairoFontMap interface.  The easiest for you I guess is to for the diamond and return PangoCairoFontMap.

Hmm, sorry for all the questions, but here's one more:

Is there any implementor of PangoCairoFontMap that does not derive from PangoFontMap? If there isn't, and isn't likely to ever be one, why not just make PangoCairoFontMap derive from PangoFontMap, like this?:

             PangoFontMap
               /     \  
PangoCairoFontMap   Pango[FT2|Xft|Fc|Win32|ATSUI]FontMap
   |
PangoCairoFcFontMap, PangoCairoWin32FontMap, PangoCairoATSUIFontMap

I don't see the need for the Interface.

OH, ignore that. I missed the "extend their respective
non-Cairo fontmap" bit. I'll figure something out.

In gtkmm, interfaces and objects share a base ObjectBase class, so casting would actually be possible (but difficult) by casting down to the base and then back up again to the interface.

But just for the record, I plan now to completely hide the PangoCairoFontMap interface in pangomm. And I believe that PangoCairoFcFontMap, PangoCairoWin32FontMap, and PangoCairoATSUIFontMap are already private API.

Hopefully people rarely need to use the PangoCairoFontMap functions (set/get_resolution(), etc). If they do, they can use the C API.