[Gtk2-perl-bugs] [Bug 347749] Missing API: Glib::Object::find_property

[gnome-perl (bugzilla.gnome.org) <bug...@bu...>]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D347749
 gnome-perl | Glib | Ver: unspecified


muppet changed:

           What    |Removed                     |Added
-------------------------------------------------------------------------=
---
                 CC|                            |sc...@as...




------- Comment #6 from muppet  2006-07-19 04:10 UTC -------
Looking over the old code, i'm unsure now as to whether the pspecs actual=
ly
stay alive if we just released the only reference to the class, so the pa=
tch's
changes to push the stuff onto the stack before unreffing the class are g=
ood.

On the other hand, the new code makes an already somewhat hair function m=
uch
larger, which isn't so great.  Unfortunately, I'm not really sure there's=
 a
better way, so i can't really so don't do that.

You now have three doc comments -- one to hide the real xsub, and two
explicitly named ones.  You should be able to remove the __hide__ comment=
, and
stick the find_property comment (without the name) to the xsub.  (That is=
, no
blank lines between =3Dcut and the start of the xsub.)

Also, the signature line for the find_property comment says that it retur=
ns a
hash; this is not true.  It actually returns a blessed hash reference.  J=
ust
call it "pspec" instead of "HASH".


I think you'd actually be fine if you changed

      if (n_props =3D=3D 0)
          XSRETURN_EMPTY;
      EXTEND (SP, n_props);
      for (i =3D 0 ; i < n_props ; i++)
          PUSHs (...);
      g_free (props);

to

      for (i =3D 0 ; i < n_props ; i++)
          XPUSHs (...);
      g_free (props);

or at the very least

      if (n_props) {
          EXTEND (SP, n_props);
          for (i =3D 0 ; i < n_props ; i++)
              PUSHs (...);
          g_free (props);
      }

For the number of properties an object is going to have, i don't think we=
'll
see any real performance difference from preextending the stack.  I'm not=
 sure
that EXTEND() gracefully handles extending by zero items; if it does, the=
n go
for that, because it's the cleanest.

But, yes, it is important that you don't leak the reference on the class =
--- if
you don't, that's one more thing we have to find and fix when trying to g=
et the
bindings to behave right in embedded perl situations.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.