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

[Jeff Clites <online@mactech.com>]

> At 23.20 -0500 1999.01.14, Jeff at MacTech wrote:
> >1) Multiple Perl apps could run simultaneously without (or independent of)
> >threading in the interpreter. They would each have a large memory
> >footprint, but a small disk footprint which would be ideal for
> >distribution.
> 
> While this may be somewhat of an advantage, I personally don't see it as a
> significant one.  If the user already has MacPerl installed, which they
> would need to in order to run these small apps, then distribution is not a
> problem now, because programs can be distributed as text.

True, but I think it would be one more step toward making perl apps feel like
real apps, and not like text files being processed by an application. This is
an advantage for people who want to use an app that someone sends them, but
they are not themselves programmers--perl apps would act like any other app
which requires a particular extension. (In this case, possibly many
extensions, which could be a problem....)

This would also coalesce the concept of a droplet and a standalone--there
would be no difference.

My main point, though, which probably got lost in my wordiness, is that as
the author of a standalone, you would have more control/flexibility as to how
your app behaves. You could muck with the menus without worrying about
killing the interpreter, you wouldn't have to worry about the presence of
windows your script didn't create, you could define what actions are taken
when you are lauched by a drag-and-drop, quit without closing other things
accidentally, etc. For CGI, you could run multiple CGI simultaneously, and
they could call one another. (Still have to deal with multiple requests to
the same CGI, but this is a different issue.) It just seems cleaner, and if
you send one of these to a non-programmer, they don't have to worry about all
of the other stuff in the menus when your app is done.

> 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.

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. 
 
> 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).

> But, if it came down to a choice, I would rather see threading in the
> MacPerl app than a shared library.

I didn't mean for them to be mutually exclusive. Threading is probably more
important, but also probably more work.
________________________________________________________________________

Jeff Clites               Online Editor          http://www.MacTech.com/
online@MacTech.com        MacTech Magazine
________________________________________________________________________



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch