Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to get the absolute path of file/dll/exe



On Friday, April 25, 2008 4:39 PM, Scott Ribe wrote:
On Friday, April 25, 2008, Mikael Hakman wrote:
Then you have drawers, cabinets, shelves, rooms, libraries, and
archives. Hierarchical structuring of information has not been in use for
20 - 30 years but for thousands....

We use this hierarchical approach because
this is the only way we know that
works for any significant amount of information of any significant variety.

Excellent points. Especially for professional users who do more than use iTunes & iPhoto.

Then given a hierarchy, we need a human-readable way to describe a
particular place in that hierarchy. We do this by making a pathname.

True. ***HOWEVER*** most users do not have the luxury of working within a
predefined global taxonomy like your examples. Most users periodically
realize that their current hierarchy needs some refinement. The Mac OS has
(and has had for a very long time) an elegant way to accommodate this need:
aliases. Pathnames internal to an app have some uses and some shortcomings,
pathnames stored as references to app-managed documents *relative* to a
fixed directory have their uses, but pathnames stored as persistent
references to user-managed documents are evil.

Yes Scott, you have some points there.

But I didn't mean professional users only. It's the amount and variety of information that calls for a structure. If I have 10 audio tracks and 10 photos, I don't need any special structure. If I have 10 thousands then the structure is as important, if not more, as the contents. Hard disk on my MBP is 250 GB. How many text documents, mp3 tracks, or jpeg images will that be?

It is clear that users need simple way to restructure the structure. But it is inevitable that if you are going to store non negligible amounts of information in your system then whether you are professional or home user, you need to think through your way of bringing order into chaos. And then you want the ability to change your mind.

A lot of software helps you do just that. Some software does it better than other. For example, iTunes can store your tracks in Artist/Album/Track hierarchy. But what about clasical music that you want to store using Composer/Composition/Piece hierarchy? Then when you want to copy some of this, in order to move it to another computer, perhaps even running other software, then you go to file system, and you use paths. If you want automate this, perhaps by using simple shell scripts (cp -r Mozart/* /some_network_dir) then paths are even more important.

I never said you should store full pathnames in your code. I said I work with pathnames in my code and convert to/from FSRef when needed.

Yes, aliases are elegant but, sorry to say, this elegance ends often up in inconsistency. Which version of the document do I look at now? Should I or Finder update the alias and when, is it already updated? Where is my previous version? In this respect symbolic links are better, IMO.

Then we shouldn't overestimate the problems. When I move a document tree from Accounts/Current Year to Accounts/2007 then the accounting software should be able to handle this gracefully provided that I inform the software that the current accounting year is 2008 from now on. If I move MyLetters to MyLetters/toFamily and then double click on a document in the new folder everything works ok, without aliases or links, on OS X and other systems.

Regards/Mikael


_______________________________________________ Do not post admin requests to the list. They will be ignored. Carbon-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/carbon-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: how to get the absolute path of file/dll/exe (From: Scott Ribe <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.