On Feb 23, 2008, at 5:15 PM, Jonathan Hess wrote:
On Feb 22, 2008, at 6:08 AM, Adam P Jenkins wrote:
On Feb 22, 2008, at 6:48 AM, Rob Petrovec wrote:
Lack of private methods is a serious flaw in Obj-C IMO.
This is silly. Private is really just about as voluntary in C++ as
it is in ObjC. If a user of your class wants to ignore your
decisions about what should be private methods, they have only to
write:
#define private public
#include "yourclass.h"
#undef private
void foo() {
YourClass obj;
obj.aPrivateMethod(); // no compiler errors or warnings
}
So declaring things private in C++ is just an advisory to users of
your class that certain methods and fields aren't intended to be
used by clients of the class, it's not meant as any kind of
security mechanism. In ObjC you can achieve the same thing by not
declaring methods in the interface file, so if a user of your class
still finds out about the method somehow and calls it, they'll get
a compiler warning and will know they're doing something not
intended by the class's author.
Note that this is in contrast to Java or C#, which run in managed
environments, and where private really can be used to fairly
securely block certain methods and fields from being accessed, when
using the correct security settings in the VM.
That said I do agree that it's nicer to have a formal language
construct for specifying what's private, like in C++, than the ad-
hoc mechanisms available in ObjC. I just don't agree that it's
really a serious flaw, more of a minor
flaw._______________________________________________
If a method is private, why would you ever want to place it in a
public header? I could see a justification for @proected applying to
methods, but it seems much better to just not have the private
methods in the interface at all. Putting a private method in the
interface says "This exists, and you can't use it." If I can't use
it, why are you telling me it is there?
I believe that in c++ the MyClass.h file is the *only* interface to
your class. In objective-c, the MyClass.h file is simply the public
interface to your class. You're free to have more than one
@interface and you are encouraged to use them to declare things that
shouldn't be part of your outward facing public interface.
Things would be best if we didn't even have to put our private
instance variables in the header -
Jon Hess
I agree that this is a way in which ObjC is actually better about
separating public from private than C++, that you don't need to add
private methods to the public header file at all, though the same
problem still exists for instance variables, at least with the 32 bit
runtime. You can get the same effect in C++ though by using the Pimpl
idiom: http://c2.com/cgi/wiki?PimplIdiom .
Adam
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
