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 underscore.
[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.
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
git://perl5.git.perl.org/perl.git
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