Re: Strong language about Cocoa and Qt.
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.