Chapter 9

In scalar or void context, the code behaves the same as before, returning a ref 

erence to the hash:

  // G_SCALAR or G_VOID context   return a reference to the new hash

  XPUSHs(sv_2mortal(newRV_noinc((SV *)hv)));

The only difference here is that since I'm in a PPCODE block, I have to manually call 

XPUSHs and mortalize the return value. Note that an XSRETURN(1) isn't required since 

xsubpp will automatically provide a return at the end of the function.

With this new XSUB, the test cases can now be written to work with both scalar 

and list context calls:

# test type_data in scalar context

my $type_data = Gnome::MIME::type_data("image/gif");

ok($type_data >{open}, "image/gif has an open key");

# test type_data in list context

my %type_data = Gnome::MIME::type_data("image/gif");

ok($type_data{open}, "image/gif has an open key");

Now, if that's not quality service I don't know what is!

Writing a Typemap

In terms of Gnome::MIME, wrapping gnome_mime_get_keys() and 

gnome_mime_get_value() as a single function returning a hash was a good choice. 

However, exploring an alternate implementation will provide a look at an 

important aspect of XS development: typemap creation. In particular, imagine 

that you wanted to provide an interface similar to one passed over earlier:

$keys = Gnome::MIME::get_keys("image/gif");

foreach $key (@$keys) {

   $value = Gnome::MIME::get_value("image/gif", $key);

   print "$key => $value\n";

}

In the preceding code, get_keys() returns a reference to an array of keys that are 

then used to call get_value().

232