Re: [MacPerl] droplets

[Bart Lateur <color@pophost.eunet.be>]

Thanks to the people who replied to reply to my post. Indeed I had
overlooked some arguments.

The main reason I would prefer the use of the data fork for storing the
script, is *uniformity*, so that there are no unnecessary differences
between scripts stored as text, and droplets.

This is the most sure way, that when adding modifications, both will work as
they should, without having to debug them both. The bugs reported earlier,
are clear examples of this. There could be more.

>A PERL droplet is an application. Macintosh applications effectively have
>their datafork reserved. In particular, for PowerPC code in a native app.

Complying to Apple's guidelines, that declare the data fork as "reserved" as
opposed to "unused", is the best argument against this.

However, I doubt it if the data fork will *ever* be used. Some people think
that it might be used for PowerPC natvie code, but this sounds very
illogical to me.

Remember that Apple built the format of application files over 12 years ago,
long before the time of the PowerPC chip, long before even the idea of
building applications for more than one processor family was born.

In that respect, putting the code into a "code" resource looks like a very
weird idea. After all, the code *is* the application, so there's nothing
more "worthy" for being put into the data fork.

But now this decision begins to make sense. You can easily add code for
other platforms simply in different resources, while still using the same
dialogs etc. In this respect, the data fork will *not ever* be used to store
code, for the PowerPC, or any other processor.


>The original purpose of the 'TEXT' resources was to allow one to
>include "required" modules, etc., so that one could distribue one file
>for a script, and not have to worry about where to find all of the
>required modules. This capability should be retained.

Good idea. But you can *still* include "required" scripts as 'TEXT'
resources, while the main script is kept in the data fork.

Bart Lateur,
Gent (Belgium)

--- Embracing the KIS principle: Keep It Simple