• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)


  • Subject: Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
  • From: Steve Checkoway <email@hidden>
  • Date: Thu, 20 Jul 2006 18:05:32 -0700


On Jul 20, 2006, at 5:34 PM, Laurence Harris wrote:


On Jul 20, 2006, at 7:56 PM, Steve Checkoway wrote:

That's impossible to believe. Do you keep all of your files in the root directory of your harddrive? In 15 years of using a mac, you've never had to double click a folder?

Double-clicking a folder is not typing a path (I did say "type a path"). It's navigating a tree. A path is a text string. However, read on and please stop trying to make it sound like I'm an idiot. I am not.

A path is a sequence of nodes in a graph. The file system is a graph (links make it not a tree). A file path as a string is just a representation of that sequence of nodes. They are two representations of the same thing. I did not mean to imply that you are an idiot. My apologies.



Have you never #include <sys/types.h> before?

Actually, no, I haven't. I've never needed to.

How about headers in your own folders? #include "foo/bar.h"? Or what about <time.h> vs. <sys/time.h>? How do you distinguish those?



All of these are using paths in a very explicit manner.

What part of using a file path is windows-ish? Every modern (and many much less modern) operating systems have had file systems that were not flat.

The practice of having users type paths to specify files and writing software that relies on paths to track files. Prior to Mac OS X Apple strongly discouraged the use of paths as file specifiers, relying instead on references that incorporated file and directory IDs. It wasn't until the Unix and Cocoa folks started writing path dependent code that moving things started causing applications to get confused and for problems to occur if a path is too long.

Is that somehow less brittle?


I organize my Applications folder into subfolders. I remember the first time I played with iDVD and tried to run its tutorial. Because I'd moved iDVD into Applications/Media, iDVD couldn't find its tutorial which was in its own bundle. Is that your idea of a feature? I've also seen Software Updater crash because an application wasn't in the Applications folder. I think they've fixed it now, but I remember when I used to drag certain applications out of their subfolders back up into Applications before running Software Updater just so it wouldn't crash.

If it couldn't find it's own bundle then that was just a stupid bug. There are two simple apis that I know of (CFBundle and NSBundle) for getting that information. As you said, those were bugs.


We didn't have these kinds of problems prior to Mac OS X. They're an improvement the Unix and Cocoa folks dumped upon us because they rely on paths.

It's been a long time since I used OS 9 but it seems like you're saying that you could take any application that had files it depended on (configuration files and so forth), put them all in different folders, anywhere you wanted, renamed them, and the application still knew exactly where they all were? How? Where was that information stored? Could you then copy those all to another computer in different locations and have it still work?


I don't think it's unreasonable for you to know where the system headers are located as a programmer even if regular uses never need to know. I also don't think it's unreasonable to want Xcode have that as a default search set. I just don't buy the claim that since you've never had to type in a path before that means you should never have to. (If you want, you can always remove the invisibility attribute on those folders and never have to worry about it again.)

--
Steve Checkoway



Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Setting up searches in Xcode
      • From: Laurence Harris <email@hidden>
References: 
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: "Chris Espinosa" <email@hidden>)
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: Laurence Harris <email@hidden>)
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: Steve Checkoway <email@hidden>)
 >Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year) (From: Laurence Harris <email@hidden>)

  • Prev by Date: Re: X Code Archives?
  • Next by Date: Question about plists and versions
  • Previous by thread: Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
  • Next by thread: Re: Setting up searches in Xcode
  • Index(es):
    • Date
    • Thread