Hildo Biersma quoted RFC 62 and then went on thusly:
> > C<XS> is an excellent medium for sharing the glory of the internals
> > of Perl with the C programming community. It is hoped that the
> > interface deescribed herein will become an excellent medium for
> > sharing the glory of the internals of well-written C libraries
> > with the Perl programming community.
>
> At TPC, Chip made the excellent suggestion that we should look at
> supporting two different interfaces: one for C and one for C++. For
> various reasons, these interfaces could offer the same functionality in
> quite different ways.
>
> Any ideas on that?
>
> Hildo
That is the direction I intend RFC 61 to go in; when I refer to "external*"
in it I am suggesting that the fortran linkage be C<use externalf> and so
on.
I think we should offer any number of interfaces, one for each language,
C, C++, Fortran, Lego Power Motor Language, anything that can be defined,
and have a clear expansion path for defining new definition languages, and
linking them in. That is why I refer to the DefinitionStructure as a type
of object on its own, analogous to a compiled regular expression in perl5:
I hope that definitionstructure compilers will appear for various languages.
C is the compiled language I am most familiar with and I have been led to
believe that its data structure linkage is very well defined, making it
suitable for the example language, and the first language.
I believe the RFC is a template for further, or more general, specs for
other languages, but C would be a good one to do first. Due to the
similarity of C and C++ data structure definition syntax, maybe both of
those at the same time -- do I get to choose the letter for C++? I'd
like to leave that to the implementor, but C<externalcpp> is the first
thing that comes to mind, along with C<externalhpp> for class and function
definitions.
Would tieing a hash to an external C++ class import all the methods and
bless the hash into the appropriate package, or would two steps be required,
in order to better support variant types? I think the two steps. (It is
possible to tie something to one class and bless it to another, is it not?)
if we are to keep the package == namespace correlation, we'll need to
define strong subpackages in order to use object methods that exist within
a name space, that's my thought on applying RFC 61 version 2 to C++.
At your service,
David Nicol
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
