On 9/30/05 9:25 AM, Denis @ TheOffice didst favor us with:
> It's really no cake walk...
> If I can comment about Apple engineers: They should have thought of that while
> making their file functions. I think it is a sure stopper when programmers
> from other sources (Like me) are confronted to that extraneous amount of
> disconvergence.
It is abundantly clear you are new to the Mac and simply do not understand
that many of these differences about which you complain allow Mac developers
to offer their users a superior user experience to what they find in
Windows, which is what people expect from a Mac. Unfortunately you keep
throwing your opinions around as if you know better than people who have
many more years of experience using and developing for the Mac and are much
more knowledgeable about it, which I would attribute to arrogance on your
part. In my opinion you should spend a little more time learning and less
time telling us how things should be done on the Mac.
> If by some miracle some Apple engineers are watching these emails.
> Here is a suggestion that would make having more software converted your way:
>
> Make high end file functionality.
> That means no FSRef, no FSSpec, no ParID, vRefnum... Just bare bones Path and
> file names
Paths suck. You probably don't understand that because you've been
conditioned by Windows to never move anything lest it break some
application. Mac users have long since had more flexibility in this regard
and we (Mac users) really have no desire for our user experience to become
less pleasant just so programmers can have an easier time of writing
software.
What you fail to understand here is that our users are not there to buy our
products. We're here to develop compelling products our users will enjoy
using. I have absolutely no interest in relying on a file specifier that
breaks as soon the user renames anything in the file's path, renames the
file, or moves the file. These things you so arrogantly want to throw away
are exactly the things that allow me to have a better experience as a user
and offer a better experience to my own users.
Unfortunately, a lot of Cocoa developers -- including, apparently, Apple's
own Cocoa engineers -- fail to understand the value of using more robust
specifiers than paths, so once I started using Mac OS X I had to start
dealing with problems I never had before Mac OS X. Yuck.
> in two flavor UniChar or UTF-8, ASCII at the limit.
I'd keep my thoughts to myself if I didn't know any more than you obviously
know. Many of your comments do little more than expose your ignorance,
whether it's about the Mac file system or Unicode. ASCII is simply not an
option for paths. And there isn't any reason you can't use paths now, except
that they limit you because many path-based APIs can't handle paths over a
1024 bytes. Ouch.
> Keep those internally to your self...
You can't keep that stuff internally if the only reference your application
has it a path. It has to work the other way around, which is why I can get a
path from things you want to eliminate, but not the other way around.
> That is what other systems do. Make it a black box like you did for
> CFString...
Wake up. FSRefs and FSSpecs *are* the black boxes. Paths are not.
> And Get rid of the damn Pascal string... It was a bad idea in the 70-80's and
> it still is.
Nonsense. Pascal strings are no worse an idea that C-strings for what they
were intended, which was text obtained from or displayed to the user.
> That would help yourself.
I understand that many people come to Mac development initially ignorant of
some of ways in which it allows developers to offer a better experience for
their users. It's unfortunate when once in a while one of them is too
arrogant to recognize his own ignorance.
Larry
_______________________________________________
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
