Re: getting a file list in sorted order
Re: getting a file list in sorted order
- Subject: Re: getting a file list in sorted order
- From: has <email@hidden>
- Date: Mon, 19 Aug 2002 12:23:19 +0100
[I'll warn folks now: lengthy OT ranting ahead. Clearly I don't have
anything better to do with my time these days than bore the pants off
y'all...;]
Steven Angier wrote:
>
> What benefits does this have over using the Finder's 'whose' clause to
>
> filter by?
>
>
I implied; you inferred :-)
Argh. (Oh well, at least I haven't yet lost the ability to spel rite...:)
>
It is the case that the Finder is not used in
>
any of the Macscript.com Library file listing functions. The distinct
>
advantage is that it works; reliably. IMHO, code that works slowly in all
>
situations is far better than code that works quickly but only 90% of the
>
time.
Quite true. Although I don't recall there being any problems with the
Finder's 'whose' clause. Code which is both reliable and fast is much
better than code which is reliable but slow.:)
>
> All the same, I don't think Finder scripting is _that_ problematic, and
>
> other stuff seems to work fine.
>
>
If you say so.
Oh, okay; 'as alias list' is broken as well. There, I hope you're satisfied
now.;p
No, really; most Finder scripting stuff seems to work just fine (if a bit
slowly on OS8/9). Considering that a lot of AppleScript and AS-related
stuff is buggy as anthills, this is not a bad track record.<g>
>
> [Most problems that arise on the lists seem
>
> to be with folk having difficulty figuring out how to do things - probably
>
> because the documentation doesn't explain it very well - not because
>
> they're running into Finder bugs.]
>
>
I think that when dealing with the Finder it is more the overall fussiness
>
of the Finder objects and events that throws new scripters, compounded by
>
the Finder's use of terms such as "file".
>
>
The classic example is to time how long it takes a new scripter to figure
>
out how to script the Finder to create a folder.
<OT>
And the reason it takes new scripters so long to figure out is that the
documentation and other teaching materials suck. The Finder's object model
is really quite logical and straightforward to work with. The problem is
that newbies roll in without any concept of what an object model is, and
assume that there's nothing more to scripting with AppleScript than
learning its sugary syntax. Which is the second biggest misassumption
anyone can make, as AS requires a fair amount of both high- and low-level
technical knowledge to use; and newcomers need to go out and learn that
stuff just like everyone else.
Except much of the reading materials are lousy, and all seem to slant
towards low-level stuff like flow control and skip on the high-level stuff
like "What is an object, and what is it used for?", presumably on the
grounds that this high-falutin' Object Oriented stuff is far more than some
lightweight beginner needs to know. Which - given that AppleScript's whole
raison-d'etre is to manipulate objects - is THE absolute biggest
misassumption anyone can make.
But this is a long-running soapbox topic for me, as I'm sure you know.
Now, if anyone wants to go and write a nice, easy-to-use, pedagogical
library that wraps the common Finder functions so that newbies can both use
it as-is and learn from it by example, I'm more than amenable to the
suggestion. Except that the abysmal state of affairs surrounding AS
libraries/modules is another long-running soapbox topic for me, so I'm
going to stop there before I veer any further off course.
</OT>
Suffice it to say that we both seem to agree that bugs aren't the primary
problem with Finder scripting.:)
(Oh, and we also agree that homonyms are bad; though I'd point out the
Finder is far from being the only culprit in this respect.)
One last point though: don't forget that mashing strings into paths with a
view to creating file system object references [aliases, etc] - which seems
to be a favourite technique of AppleScripters everywhere (myself included)
- is an inherently dangerous act that can have all sorts of unintended
consequences. I'm sure lots of folks would love it if the Finder worked
this way... but they should be jolly careful what they ask for, lest they
ever get it.
>
> Mmmm... I did some checking (OS9.2.2./AS1.6). Depends what you're
>
> definition of "right answer" is[...]
>
>
I didn9t realise that the Finder "hides" the desktop folder in this way.
>
IMHO, this is another strong reason for avoiding its use. Perhaps the Finder
>
also hides things such as Temporary Items?
Not at all. It's merely reflecting the modus operandi of its GUI side,
where the desktop folder for each drive is similarly hidden from view.
Most problems here seem to arise from Mac users' fuzzy notion of what
comprises OS, file system and applications. The Finder - despite
appearances - is not the OS, and its representation of the file system is
not a literal one. In scripting the Finder, you're manipulating the Finder;
*NOT* the file system.
The Finder manipulates the file system for you - this is the Mac Way
(safety and simplicity first). If you want more direct access to the file
system than the Finder permits, crack open a UNIX terminal for a seriously
different philosophy. [Though do note that, even there, the file system
representation you see is still an abstracted version of the real thing.]
Getting back to the Desktop and Temporary Items folders though, the Finder
provides other objects for working with those; it certainly doesn't
obstruct their use. Its scripting interface merely maintains consistency
with its visual interface. The problems arise when folk assume that its
scripting interface represents the file system, which is does not. But if
this is your beef then again I'd state that the correct remedy for this is
a pedagogical solution, not a technological one.
>
> ======================================================================
>
>
>
> Again though, this seems a pretty inefficient way of performing a very
>
> simple task that's so easily [and quickly] performed using the Finder and a
>
> simple 'whose' clause [8 lines of code versus 1, plus a whole bunch of
>
> relatively slow AS operations and osax calls].
>
>
I presented an option of doing it on one line:
>
>
FilterFiles(theFolder, theAllowableTypeList, theAllowableCreatorList)
The "how many lines" argument was amateurish and incompetent, and I
withdraw it on the grounds that I really ought to know better by now. The
rest I stand by.
>
> You only really want to use such things when you're going to get some
>
> worthwhile benefits from it, doing things that you can't do with the Finder
>
> alone (e.g. filter files according to content, or processing items as you
>
> go).
>
>
The worthwhile benefit is the peace of mind that list folder is reliable.
Hehe... I just saw Chris Nebel's post on the subject, and am forming the
view that reliability in AppleScript is a relative concept at best. Anyone
for Voodoo?:)
Cheers,
has
--
(My email address has changed from <email@hidden> to
<email@hidden>. Please update your address books accordingly.)
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.