• 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: Apple and Developers (was lots of different subjects)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple and Developers (was lots of different subjects)


  • Subject: Re: Apple and Developers (was lots of different subjects)
  • From: "Andrew R. Mitchell" <email@hidden>
  • Date: Sun, 24 Mar 2002 12:05:42 -0500

4) Bring back <insert technology here> - Whether it's EOF, MacApp & ACS, Dylan, V-Twin, Open Transport Streams, etc., there are technologies that certain developers find key to their particular area of expertise

_A flexible database-access API is *NOT* "a technology that certain developers find key to their particular area of expertise". It is rather a sine qua non for any environment_.

I am really not trying to start a flame war here. Actually that was the exact opposite of what I was trying to do. I totally support EOF and think that it's return is crucial for the platform. But based on the arguments you're making, why are any of the following less important:

MacApp & ACS - Many commercially shipping applications rely on these and they will be very difficult for the developers to remove. I know of one app that is due to ship this summer where the company's product has been rewritten from the ground up to take advantage of OS X. Guess what framework they used? MacApp.

Open Transport Streams - If you really want to start a flame war take a walk over to the Open Transport groups (now macnetworkprog), and tell them that Streams are an unimportant API that does not allow them to do networking in a much more flexible manor then BSD Sockets. Trust me, you'll find people as ardent about the loss of streams as about the loss of EOF. In my opinion the Mac needs them both.

V-Twin (aka AIAT) - If you had an application that relied on using V-Twin to do full text searching of documents that are not stored on the file system (like in a database perhaps), you're out of luck under OS X since Apple has severely limited it's usability. Based on reading this list, I think Cocoa probably has had similar functionality removed (is this what DigitalLibrarians were?) but I am not an OpenStep/NextStep/Cocoa expert so don't quote me.

Dylan - OK, this is really only one of my pet peeves (and probably doesn't rank up there with the loss of EOF), but I do know many developers that agree with me. As much as you all love Objective-C for the power and flexibility it gives you, we (those of us who have tried it) love Dylan. If you read my posting on Macintouch, since I don't truly expect Apple to do anything with Dylan (which is a shame) my goal was to them to move most of the functionality into their Objective-C environment since they clearly state Objective-C is capable of it. And after all, don't we all want better and more powerful tools?

In short, I support all of these technologies, *INCLUDING EOF*. I'm sure I missed several equally worthy technologies in my list, but I was not attempting to be comprehensive. I also was not attacking EOF in any way shape or form. If you think I was, you missed the point of my email. For not making it clear enough I apologize.

Andrew
--
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Apple and Developers (was lots of different subjects)
      • From: Scott Anguish <email@hidden>
    • Re: Apple and Developers (was lots of different subjects)
      • From: Ondra Cada <email@hidden>
References: 
 >Re: Apple and Developers (was lots of different subjects) (From: Ondra Cada <email@hidden>)

  • Prev by Date: NSrange utilities
  • Next by Date: Re: Determine whether class is subclass
  • Previous by thread: Re: Apple and Developers (was lots of different subjects)
  • Next by thread: Re: Apple and Developers (was lots of different subjects)
  • Index(es):
    • Date
    • Thread