Re: Stop stepping on other perl extension's toes

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

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

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

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

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]