[RfC] Extension API

[Mattia Barbon]

hello,
parrot.h mentions that extenders should include extend.h, which does not
exist (yet); below there is a list of the headers that look useful for
extenders (of course the final decision needs to be done at the function
level).

Comments?

Regards
Mattia

embed.h
debug.h
exception.h
exit.h
io.h
memory.h /* requires Parrot_ prefix */
misc.h
method_util.h /* not sure, *looks* useful */
pmc.h /* requires Parrot_ prefix */
string_funcs.h /* likewise */
vtable.h /* likewise */

these are mainly nice-to-have (why reinvent these wheels *again*?),
but not strictly necessary

hash.h /* requires Parrot_ prefix */
intlist.h /* likewise */
key.h /* likewise */
stacks.h /* likewise */

[Brent Dax]

Mattia Barbon:
# parrot.h mentions that extenders should include extend.h,
# which does not exist (yet); below there is a list of the
# headers that look useful for extenders (of course the final
# decision needs to be done at the function level).
#
# Comments?

Extenders should only use functions defined in extend.h and (notionally)
implemented in extend.c; they should not use any of the headers
mentioned below (besides perhaps embed.h). Thus, none of these headers
should be included as-is. However, it's quite likely that the
embedders' functions will be thin wrappers around functions implemented
in these headers.

Some time ago, I posted a draft PDD describing the functions embedders
and extenders may use to manipulate data. That PDD was never accepted,
but reading it may give you some ideas.

--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism