Re: Stop stepping on other perl extension's toes
- From: Torsten Schoenfeld <kaffeetisch gmx de>
- To: gtk-perl-list gnome org
- Subject: Re: Stop stepping on other perl extension's toes
- Date: Sun, 28 Nov 2010 20:36:01 +0100
On 28.11.2010 07:23, Florian Ragwitz wrote:
* The new API needs some short POD paragraphs, maybe similar in
structure to what gperl_set_isa and gperl_prepend_isa have in
GType.xs.
See the commit message. I don't consider the functions I added to be
useful as a public interface. If a module wants to attach random
pointers to arbitrary SVs and doesn't want to actually implement all of
the hairy magic business, I believe it should just be using
XS::Object::Magic.
The reason for me making the symbols public is because they're needed in
a couple of places other than GObject.xs where Glib and Gtk weren't
reusing the infrastructure of GObject.xs for various reasons. Short of
making those places do their job in a different or leaving them as buggy
as they were, it seemed to be a reasonable thing to do to share the
implementation.
This is the reason the functions I added are rather lax in their
argument checking. They're supposed to be called from a site already
checking those things, such as gperl_get_object or
gperl_get_object_check.
Agreed. But what you wrote above is exactly what needs to be present in
POD form: purpose, assumptions, caveats. Whatever appears in gperl.h
and is not marked as private (by a leading underscore, say) becomes part
of our public API.
[MGf_DUP, svt_dup]
In addition, an svt_dup callback can also eliminate the need for
tracking all perl gobjects as well as the associated global
lock. However, this series of patches isn't going there just yet.
Oh! I didn't know about this hook into cloning. Very interesting and,
as you note, the perfect replacement for the object tracking stuff.
But this makes me wonder: if in the future we start putting callbacks
into the MGVTBL, then every user of the new functions will automatically
also get these callbacks. I don't think we want that. So, should the
MGVTBL become a parameter of all the new functions?
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]