Re: [MacPerl] droplets

[Matthias Ulrich Neeracher <neeri@iis.ee.ethz.ch>]

Bart Lateur <color@pophost.eunet.be> writes:
>In the last two months, there have been (at least) two posts of people
>having trouble with files that used to be droplets, but have been edited and
>saved as text since then.
>
>All this has to do with the fact that droplets store their script in a
>resource, type "TEXT", ID 128 (or so), and name "!". These resources are not
>destroyed when save a script as text on top of what used to be a droplet.

Yes, this is a bug in MacPerl (though I though I'd fixed it in MacPerl 5; I'm
not sure).

> So the old "TEXT" resource is retained. What's worse: MacPerl seems to have a
> preference to use this "TEXT" resource, over the text in the "normal" data
> fork.

I thought I'd fixed that, too.

>I've experimented a little with droplets. I found out that with droplets,
>the data fork is *empty*. This is where text files keep their text. So I can
>see no good reason why this use of a "TEXT" resource. Just think along with me
:
>
>1) If droplets were to store their script in the data fork, the bugs like
>the one this post started with, would simply vanish forever.

True.

>2) MacPerl's task would be a *little* simpler. MacPerl needn't check the
>existence of a "TEXT" resource, before looking at the data fork.

Not true. The TEXT resource would still be needed for fat runtimes and possibly
other future packages.

>3) You could edit droplets using BBedit.

No. Putting text in the datafork doesn't make the file a text file, and even
though BBEdit handles binary files, it can't deal with packages correctly.

>4) I have noticed that if you have a little trouble with your files (a
>little damage), the resource fork is easily damaged beyond repair.

Somewhat true, due to the complex format of resource files.

>There are only futile arguments against this:

Is that "Argumentum at Borg" ? (Resistance is futile, you will be assimilated)

As other have pointed out, the following facts apply:

 - Most packages which include PowerPC code don't have the data fork free for
   data.
 - At the time the droplet mechanism was designed, it was not clear if 68K only
   applications would be allowed to have data forks.

>So I would suggest to Matthias to change this "save as" thing in MacPerl, so
>that it's script is saved in the data fork from now on.

Even if using the data fork *had* advantages (which is not entirely clear to
me), many of them would be negated by the need to remain packward compatible
with existing droplets.

>Ok, that's the bulk of my post. Now as an aside, about this
>&MacPerl::Quit(level) thing. In summary, you have the following possibilities:
>
> &MacPerl::Quit(LEVEL)
>   If LEVEL is 0, don't quit after ending the script.
>   If 1, quit if running under a runtime version, 
>   if 2, always quit. 
>   If LEVEL is 3, quit if this was the first script to be run since
>starting MacPerl.
>
>None of them gives the desired result if run from a droplet. My intuition
>says: "quit if MacPerl was started up by this droplet". That is not
>possible. LEVEL=3 comes closest, but if you open MacPerl, open a script in a
>window without running it, and then start up a droplet containing this
>"&MacPerl::Quit(3);" line, MacPerl will be terminated if it is executed.

You have a point. Time for level 4, then :-)

Matthias

-----
Matthias Neeracher   <neeri@iis.ee.ethz.ch>   http://www.iis.ee.ethz.ch/~neeri
   "One fine day in my odd past..." -- Pixies, _Planet of Sound_