I've just pushed a branch "enum-constants" which a commit that makes Glib add constant numeric subs for each value of each enum or flags type registered with it. This allows to call Glib::IOCondition::HUP to get 16, or Pango::Weight::BOLD to get 700.
https://git.gnome.org/browse/perl-Glib/log/?h=enum-constants https://git.gnome.org/browse/perl-Glib/commit/?h=enum-constants&id=361ba7d55f045ea6113479e5798f4213ee7e7dff This is useful when a function, signal or property expects or returns an enum or flags value, but the API specification is such that our special enum and flags string handlers are not invoked. Example: Gtk3::TextTag's "weight" property accepts any positive integer but predefined values are given by the Pango::Weight enum. The downside of supporting this niche application is a slight increase in load time. On my machine, I see the following increases for "perl -M<module> -e0": Glib: 1% Pango: 3% Gtk2: 9% Gtk3: 9% So: Are the benefits of the new functionality worth the increase in load time? _______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list