[MacPerl] Re: MacPerl for stand alone apps

[Henry Penninkilampi <htp@metropolis.net.au>]

Robert Pollard <robpoll1@bellsouth.net> wrote:

>I have been looking at MacPerl as a potential development tool for full
>blown applications.  I have seen many examples of MacPerl's capabilities
>but I have not seen a full blown application yet.  Given the power of
>MacPerl's language I have no doubt it can handle a lot of advanced data
>filtering, file manipulation, etc., but what happens when you build a
>runtime application that accesses an Oracle database of 100 tables and
>has 40 different forms using cursor tracking activities, visible arrays,
>pop-up lists, etc?
...
>Would MacPerl be powerful enough and fast enough to meet all of the
>needs of stand alone application requirements?  I don't know if MacPerl
>has a compiler or if it produces fast code.  Can you produce
>multi-tasking processes?  i.e. a process that runs in the background to
>know when a user has logged on to the system which will notify the
>current user no matter what they are currently doing in the software.

Possibly a more important issue here is that even if you use MacPerl to 
create a stand-alone application, all someone needs to do is drag-drop 
your app onto MacPerl and they have instant access to the source code!  
(Well, at least that's what I was able to do using 5.1.8r4.)

It looks like when MacPerl builds a stand-alone application, it 'simply' 
bundles the interpreter with the code.  This makes the whole thing nice, 
neat, and portable, but provides no security for the code-base, and I 
would hazard to guess that it would provide no speed benefit either (over 
running the same code in script form).

As for multi-tasking, the example you provide above doesn't actually need 
multi-tasking capabilities.  It can be done by a separate monitoring 
application simply scanning the process table for instances of the client 
application - upon detection of a client app, it could interrogate it 
using AppleEvents and then take action based on the information provided. 
 Alternatively, launching a client app could (again, using AppleEvents) 
send information to the monitoring app as part of the initialisation 
procedure.  Not quite as elegant as forking off a child process which 
monitors the parent (or vice versa) but, hey, it works.

Henry.

===== Want to unsubscribe from this list?
===== Send mail with body "unsubscribe" to macperl-request@macperl.org