I thought the purpose of CamelBones was to cross the bridge between ObjC and Perl.
It is - but a bridge works both ways. The most popular use of CB, by far, is to work with Cocoa objects from Perl. But it works just as well the other way around - you can link CB to your ObjC app, and use it to work with Perl objects, scalars, functions, etc. from Objective-C.
Or does creating a framework necessarily mean that you need to provide an ObjC interface to its functionality?
No, a framework doesn't even necessarily have to have any code at all - it could be nothing but resources. But, we weren't talking about generalizations - you mentioned creating a framework that provides a version-neutral interface to libperl. Such a framework, by virtue of what it's trying to accomplish, requires a public interface that's separate from that of libperl.
An application *could* link against the framework, and then simply use the standard Perl embedding api, but doing so would gain nothing - the resulting app would be as tightly bound to that version of Perl as it would be if it had been linked to libperl directly.
In order to provide a version-neutral interface, you need to expose a set of functions and/or methods that are implemented in the framework itself. Applications then use that API instead of that of libperl. As a result, they're dependent only on the framework API; they're independent of the libperl hiding behind it.
sherm--
Welcome to Rivendell, Mr. Anderson.
