At 1.55 -0500 2000.03.10, Joshua Juran wrote: >Right. But to be pedantic, it's not the access to powerful functions /per >se/ that's dangerous, but the unfiltered interface to them. I somewhat disagree. First, MacPerl's toolbox modules are not entirely stable. There are bugs. So this is the first problem. Second, even a filtered interface, without background inteligence, can be dangerous. If I call MacWindow->new, I can still pass it bad arguments. The danger is reduced, but not eliminated. >I just had a different idea: Instead of putting an application framework >into MacPerl, how about putting MacPerl into an application framework? I >just happen to have one, and it's open source... Here's how this would >work: The app framework would have an embedded Perl interpreter, somehow >modified to provide an interface to the added functions. Then some modules >would wrap around that, providing an object layer. This sounds interesting ... in case you missed it before, Matthias is working on the next version of MacPerl (based on 5.6, which, for Unix, just entered the release candidate stage) and it may very well include a perl shared library which will ease embedding tasks, I believe. So you may want to wait and see how that pans out (or volunteer to help him). -- Chris Nandor mailto:pudge@pobox.com http://pudge.net/ %PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6']) # ===== Want to unsubscribe from this list? # ===== Send mail with body "unsubscribe" to macperl-request@macperl.org