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

[Jeff Clites <online@mactech.com>]

I'm afraid that my main point is being lost, so I will restate it before
responding to individual points:

My main point is that perl is being positioned as a general-purpose programming
language, rather than an often-ported Unix tool. To this end, it is desirable
for it to behave as much as possible like any other programming language, from
the perspective of users of perl apps, and from the perspective of perl
programmers writing Macintosh-style (Toolbox-based) apps. I believe that a
shared-library approach would take a large step toward this goal.

>From the user's perspective, it's best to be able to run an app by
double-clicking it, see its name in the Applications menu (rather than the name
of the language), and have it quit when it is done (or when the user tells it to
quit)--and not to have to deal with the interpreter application directly. As a
user, I shouldn't have to concern myself with what language has been used to
implement a program I am using. Imagine if C operated this way: I would have to
launch CodeWarrior to run MS Word, I could only run one C application at a time,
or (by way of comparison to a threaded perl interpreter) I could run multiple C
apps but if one crashed they would all come down. This would be an intolerable
state of affairs. Perl still behaves this way, but I see a way out of this (a
way which is quite similar to the Java model).

>From a programmer's perspective, I should be able to create menus and windows
without having to deal with those of the interpreter.

Key advantages:

As mentioned before...

1) You can run multiple apps simultaneously.

2) One app crashing does not bring down other apps. (A threaded perl interpreter
doesn't solve this.)

Also...

3) Memory leaks are cleaned up when an app terminates, without having to quit
all other perl apps. (Presently, and probably even under a threaded MacPerl, you
have to quit the MacPerl app to cure leaks, such as those left by HTML::Parser.)

4) You can run multiple CGI simultaneously, and they (or other perl apps) can
intercommunicate via AppleEvents, just like any other Mac app.

5) To go along with (4), your app can install AE handlers to enable it to
respond to whatever AEs it wants. Even under a threaded MacPerl, such handlers
would be interpreted as handles of the MacPerl app, not as handlers of you
script. In particular, multiple simultaneously running perl apps are seen as a
single process by the Process Manager and the AE Manager, so they don't each get
to have their own AE handlers--so it doesn't seem possible to have two MacPerl
apps communicate via AEs under threaded MacPerl.

6) The user doesn't ever have to see the interpreter/IDE, and wonder what the
heck it is.

I think these are significant advantages, and I don't see any disadvantages.

Specific points:

On 1/15/99 at 11:44 AM, Chris Nandor <pudge@pobox.com> wrote:
> 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.

No--you can certain save scripts as text files and run them as you do now. But
if you want to be able to talk to a specific script via AEs, or have two scripts
talk, you would have two choices (rather than none):

1) Allow them to all have the same creator codes (as AppleScipt apps have when
saved from the Script Editor), and target you AEs based on name (ultimately,
ProcessID).

2) Or, give them distinct creator codes and target them with this. This is
probably best if you are sending these to non-programmers to use, since they
might change the names. This is also the appropriate option if you have a script
which produces output files, and if you would like to be able to launch this
specific script by double-clicking on one of these files in the Finder.

The shared lib approach doesn't force you to do anything, but it enables you to
do things that are either impossible now or require a large deal of
circumlocution. Of the hundreds of scripts you may have, probably only a handful
need to be manipulated in this way.

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

It definitly works--it isn't particularly difficult to do from C. It's sort of
apples and oranges, though, because the shared lib would be devloped by Matthias
or you or me or whoever, but using the Process Manager would be done by
individual script authors, as needed (although we could write perl interfaces to
hide this).

[edited]
> I don't see how it would be any different than the situation now.  Now
> without standalone:
...
> 3.  Run this text file in MacPerl from the Run ... command.
> 
> With shared library:
...
> 3.  Run this (small) app by 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.

I agree that this is somewhat a minor point. On the other hand, the latter is
the Mac way of doing things, and the former is quite like the DOS way. (If we
can make things more Mac-like, why not?) Compare:

Running a perl app under WinNT:

1) Open a console window.
2) Specify the perl app to run by typing its name on the command line.
3) When the app is finished, close the console window.

Running under MacPerl:

1) Open MacPerl.
2) Specify the perl app to run by choosing it through the Open... menu command.
3) When the app is finished, close MacPerl.

With the shared-library version, a MacPerl app would behave just like any other
Mac app. That's what user-friendliness is all about.
________________________________________________________________________

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