On Wednesday, February 26, 2003, at 08:41 PM, Sherm Pendley wrote:
On Wednesday, February 26, 2003, at 09:11 PM, Ken Williams wrote:
Maybe a way to do this would be to package up a bunch of this stuff as a framework that people could have installed into /Library/Frameworks/ ?
Yes, that sounds good. And then that framework could expose a public, version-neutral API, so that applications that want to embed libperl can link against the framework, and thus be insulated from changes to Perl itself. Maybe it could even come packaged with project templates for building apps that are linked to it.
Perhaps we could give this framework a clever name - something suggestive of the framework that a camel is built around. CamelSkeleton... CamelFrame... CamelBones! Yeah, that's a good name for it.
I thought the purpose of CamelBones was to cross the bridge between ObjC and Perl. What Rich seemed to be proposing was just packaging libperl, with a few standard mac-ish modules, into a framework so people could build regular-perl applications on it. Just because two frameworks include libperl doesn't need to mean that they make each other redundant, does it?
Or does creating a framework necessarily mean that you need to provide an ObjC interface to its functionality?
-Ken
