• 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: Strong language about Cocoa and Qt.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strong language about Cocoa and Qt.


  • Subject: Re: Strong language about Cocoa and Qt.
  • From: Sailor Quasar <email@hidden>
  • Date: Tue, 1 Jul 2003 20:02:38 -0400

On Tuesday, July 1, 2003, at 07:02 PM, Jeff Harrell wrote:
I assume (though I haven't really tried) that you can hide a method (by putting it in a category instead of in the header file), but you can't prevent people from calling it.
Many people don't realize that you do *not* have to declare your methods in your interface. It's perfectly acceptable to have methods in the implementation that are not declared in the interface. The worst you'll get is a compiler warning, and if you order your methods right you won't even get one of those.

This doesn't prevent people from calling your methods, but it saves a lot of trouble in documentation. Don't bother documenting a public interface for a method that is never meant to be called.

I've gotten into the habit of declaring my public interface in the header and then using a category in the source code file to declare the private methods; this saves me having to pay careful attention to the ordering of the method implementations, and has the added advantage of using the language to separate out the public from private implementations (something I used to use #pragma mark extensively for anyway). It is my personal opinion, which I'm sure many do not share, that it is bad form to not declare methods (or functions either, I always force compilers to require prototyping when I'm working in pure-C) :).

As for others being unable to call private methods/functions, all the other programmer needs to be able to do is grep your symbol table and know how the compiler mangles the language you used; dyld functions provide the rest. The question is why someone else would go to so much trouble to find an SPI, and what functionality is so glaringly missing from your public API to make them do so.

Again, this is probably because of the way I've been trained, but using a dynamic language always makes me a little uneasy.
It is not generally necessary for you to use id. I'm in the habit of declaring a type for all of my variables.

It's not always necessary, no, but I've found that it's a real timesaver when you need to have a delegate or use formal protocols. That being said, I take pains to declare static types whenever I can, and to use the id <protocolName> form for formal protocols whenever possible before falling back on plain id. Objective-C's dynamic typing is very powerful, but as they say, with great power comes great responsibility :).

-- Sailor Quasar, guardian of Leraz's memory
"A face of stone may hide a soul with the deepest Love of all"
Email: email@hidden
_______________________________________________
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: Strong language about Cocoa and Qt.
      • From: publiclook <email@hidden>
References: 
 >Re: Strong language about Cocoa and Qt. (From: Jeff Harrell <email@hidden>)

  • Prev by Date: NSString stringByTrimmingCharactersInSet: strangeness
  • Next by Date: Hardware Asset
  • Previous by thread: Re: Strong language about Cocoa and Qt.
  • Next by thread: Re: Strong language about Cocoa and Qt.
  • Index(es):
    • Date
    • Thread