Re: [MacPerl] Perl app framework (Using ' instead of :: ...)

[Joshua Juran <wanderer@metamage.com>]

At 9:40 AM -0500 2000-03-08, Chris Nandor wrote:
>At 21.56 -0500 2000.03.07, Joshua Juran wrote:
>>What if instead of providing (essentially) direct access to the Toolbox
>>calls, we had modules that implemented objects, like, say, a Window?
>>Window->new() would call [Get]New[C]Window as appropriate, and when it went
>>out of scope, (it automatically calls DisposeWindow, and) the window goes
>>away.
>
>Well, we do have such functions.  Specifically, we do have a
>MacWindow->new.  But they are still somewhat dangerous.  For instance,
>Mac::Glue and Mac::AppleEvents::Simple offer a much easier interface to
>Mac::AppleEvents.  But they can still crash your machine, because you are
>accessing powerful stuff, and if you pass bad arguments to the functions,
>you can lose big-time.

Right.  But to be pedantic, it's not the access to powerful functions /per
se/ that's dangerous, but the unfiltered interface to them.

>
>>If your script dies, the window goes away.  If MacPerl runs out of
>>memory and aborts your script, the window goes away.
>
>That is somewhat difficult to do, and more importantly, we need someone to
>do it.  Volunteers are most likely welcome, but you'd have to talk to
>Matthias about it to make sure you aren't developing something incompatible
>with his plans for the modules.

I don't know if the level of reliability I'm seeking is possible through
modules alone.  It may require modifying the MacPerl engine itself.

>>This is on my list of projects to take on if someone doesn't beat me to it,
>>but there are many projects ahead of it.  Is anyone interested in using or
>>developing such a beast?
>
>I am sure lots of people are, and perhaps everyone on the MacPerl list.  :)

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.

You would include a main driver script; possibly as a resource or possibly
as a neighboring text file (to make development easier).  On startup, the
app would compile and execute the script, which would install menu handlers
(possibly changing the default menus).  For example, when a user of the app
chooses File::New, your handler might create a new document object (and
store it somewhere, so it doesn't go out of scope and vanish when your
handler exits), :-) or you could leave the default handling in place and
just override the new-window handler.  (TMTOWTDI.)

Hey, there's next year's MacHack paper. :-)

Josh


Josh

--
Joshua Juran                          Metamage Software Creations
=)                                         Tools for Wizards
wanderer@metamage.com
<http://www.metamage.com/>   * Creation at the highest state of the art *



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