Re: [MacPerl] Using UNIX style filenames with MacPerl

[Matthew Langford <langfml [at] eng [dot] auburn [dot] edu>]

On Mon, 18 May 1998, Vicki Brown wrote:

> When writing "category 0 code" (used by yourself and no one else)
> embedded path names are (if not the best coding practice) perhaps
> acceptable.  As the code passes into category 1 ( aka "alpha" or used by
> friends) and category 2 (aka "beta", friend of friends), hard-coded
> paths are less acceptable.  As are hard-coded constants. 

Oh, poppycock.  Should the value of pi be an environment variable, or
supplied on a commandline?  If I've established a reasonable directory
tree for my project, must I use a wealth of env vars or commandlines
without defaults?  This line of thought is narrow, and not applicable to
situations I have encountered. 

Worst of all, it flies in the face of the spirit of Perl:  There's More
Than One Way To Do It.  The reason I most like Perl is that I can do
things the way I think of them, and get things to work quickly.  99% of my
coding will never be a module on CPAN, quick one-off scripts that get the
job done.  Many must be done within hours, or Da Boss will be breathing
down my neck.  Some are done while Da Boss is breathing down my neck (he
likes to hack around in perl, too).

Having said all that, it is true that there are workarounds, and
translation is merely a convenience.  It reduces the usefulness of MacPerl
in testing scripts intended for Unix, and increases the tasklist of
porting to MacPerl. 

I don't believe a module can solve the problem (although File::Spec comes
close for my needs).  For me, right now, the most convenient solution is
just to use real, er, Unix perl through a terminal window. 

> So (imo) much of the discussion we are having involves a desire to modify
> MacPerl to deal with code that should have been written differently in the
> first place.

I challenge you to find one place in the Camel book, either edition, where
hard-coded paths are deprecated.  Even I regret the inflexibility of
#!/usr/local/bin/perl, but that's another story.

You are coming at things from a production-code point of view, or even
more, a favorite-Apple-soapbox coding point of view.  Great, but other
valid points of view exist.  Especially in the perl universe. 

I don't pretend to have your experience or knowledge; but with such
experience as I have had, my mileage has varied considerably.


--
MattLangford 



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch