Re: Stop stepping on other perl extension's toes

Torsten Schoenfeld <kaffeetisch gmx de> writes:

On 28.11.2010 07:23, Florian Ragwitz wrote:

[new functions should be private]

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.

Fair point. I suppose I'll do that, and also prefix the symbol with an

[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

It isn't documented particularly prominently. All perlxs has to say
about coping with threads is MY_CXT and the per-package CLONE hook,
which is really not the best tool to hook into per-instance cloning, but
intended to help with static data on the C level.

I guess I'll be working on a patch adding a paragraph or two about
MGf_DUP there.

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?

You do make a good point. However:

  - the purpose of these functions is to attach a pointer to SVs

    I now realise the naming doesn't make that entirely clear. I guess I
    could be renaming them to gperl_attach_{struct,ptr,whatever} etc.

  - we now can apply more than one kind of magic

    If we decide to use svt_dup, there's nothing forcing us to provide
    that in the same MGVTBL we use to identify the magic we use for
    attaching pointers.

  - even if we want only one kind of magic, it's still not a problem

    Even if we would want to do that, that doesn't mean the svt_dup
    implementation couldn't just delegate to a function specific to the
    kind of pointer we associated with the SV, for example by not
    storing the pointer in mg_obj directly, but storing a struct with
    both a dup func and the actual ptr, or whatever.

  - it's not our responsibility to provide this API

    If anyone other than us wants to use this functionality, he's free
    to use XS::Object::Magic. The goal here is not to provide a general
    purpose API - that already exists.

  - it's explicitly private

    We are free to change the API whenever we feel like it.

I'm not saying that any of this is a good idea. The point is "I don't
know yet", and "they're private".

On a related note, I've pushed a rafl/mg_ext branch to

That implements much of what my Glib change does directly in the
core. Incidentally, it does have an MGVTBL *parameter, as you suggested.

Once that's in, one of the possibilities would be to provide the same
API on older perls using Devel::PPPort. That would be an ideal thing to
use in the places outside of GObject.xs, where we really just want to
attach opaque pointers instead of GObjects.

With that, we would be free to properly privatise the functions I added,
allowing us to use whatever hooks we want in our MGVTBL, keeping our
vtbl and the way we use it nice and private.

Attachment: pgpJ4xiOjNPFD.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]