Re: [MacPerl] Perl Shared Library (was Re: [MacPerl] ports andbuilds)

[Chris Nandor <pudge@pobox.com>]

At 11.30 -0500 1999.01.15, Jeff Clites wrote:
>> I am not against having a shared library, but it does not solve the primary
>> problems we have with multiple processes, which involve launching a script
>> from the Finder or trying to talk to MacPerl via Apple Events.
>
>Launching from the Finder would be solved, in that your apps would be 100%
>bona-fide real Macintosh applications, so they should be given distinct
>creator codes.

Wha ... ?  I have hundreds of perl programs lying.  Each one gets its own
creator code?  That makes no sense to me.  It seems completely undoable.


>Secondly, though, even with the same creator codes, you can target
>AppleEvents based on ProcessID, and you can use name and FSSpec in addition
>to creator code to help you decide which process to target with an AE. This
>is cleaner and more in line with the normal way of doing things than sending
>all of your events to the "main" MacPerl app with additional info about which
>script to run. This lets you thing of your scripts as apps rather then
>scripts.

That could possibly work.  I guess the work it would take to make this work
would be minor compared the work it would take make the shared library in
the first place.


>> I don't know if it would make MacPerl more stable or not.  As to
>> automatically updating other apps, well, few MacPerl apps in my experience
>> are saved with the interpreter (as standalones), so this is not currently a
>> common problem, though you are correct, it would benefit the case of the
>> standalone.
>
>To reiterate, for distribution it would make sense to send standalones (which
>would be the same as droplets). Currently this is not commonly done, probably
>because (a) they are prohibitively huge and (b) people usually don't send
>apps to non-programmers, because there would be a boatload of explanation
>involved (ie, the "new" way would allow small tasks to be solved by small
>executables which required a small amount of explanation).

I don't see how it would be any different than the situation now.  Now
without standalone:

1.  Install MacPerl if you don't have it.
2.  Install these modules if you don't have them.
3.  Run this text file in MacPerl from the Run ... command.

Now with standalone:

1.  Run this (huge) app by unpacking it with Stuffit Expander and then
double-clicking it.

With shared library:

1.  Install MacPerl if you don't have it.
2.  Install these modules if you don't have them.
3.  Run this (small) app by unpacking it with Stuffit Expander and then
double-clicking it.

I see benefits to all three forms, but no clear benefit in the latter for
distribution.  Well, once MacPerl gets installed, it is more Mac-like, and
that much is good.  But the benefits certainly seem minor to me.

--
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 mac-perl-request@iis.ee.ethz.ch