What do you gain by deciding (and forcing) what a user of the code
can and cannot do with it?
Is that not the whole reason that @public, @protected and @private
are used? To limit what the user has access to?
We write classes that provide a certain functionality to the user of
our class. We define what a user can and cannot do with our class. I
agree that it is in the best interest of the users not to poke around
in our private methods but accidents happen unfortunately and isn't
it our job as a developer to protect against such events? Isn't half
the code we write put there to fix errors, bugs or to prevent
possible errors? We, as developers, should not develop code that has
a known error and submit it on the basis that we trust the end user
will have the sense not to call the wrong function. Accidents happen.
Phil.
On 22 Feb 2008, at 12:41, João Pavão wrote:
I don't agree at all. :)
Whatever you declare in the header file of your class will be the
public API that establishes the "contract" between you and the
users of your code. "If you use my class this way, it will behave
correctly and do this and that stuff for you". It's in the best
interest of the users of your code to not shoot themselves in the
foot, so they're likely to follow good practices and avoid poking
around your private stuff so that their stuff works flawlessly, and
remains so even after they perform an update of your classes to a
more recent version.
What do you gain by deciding (and forcing) what a user of the code
can and cannot do with it?
--
João Pavão
On 2008/02/22, at 12:16, Philip Bridson wrote:
I agree.
Your point hit the nail on the head and is exactly the reason that
I do not want this method to be public. If it is called externally
it will cause an error. Even if I put the 'private' method into
the .m file it can still be found by using the pop up list of
methods available. Although, why some one would want to try to do
something they are not supposed to is a mystery, but that does not
mean that someone won't try.
Thank you all for your help.
Phil.
On 22 Feb 2008, at 11:48, Rob Petrovec wrote:
Lack of private methods is a serious flaw in Obj-C IMO. There
are just as many reasons why someone would want to make a
variable private as they would want to make a method private.
For example if your writing a class that is part of a library
that other developers will be using (quite common in large
projects). You may want to hide implementation details from
them, or prevent them from calling a method that requires another
to be called before/after it in order to work properly etc (in
other words, prevent them from shooting themselves in the foot by
calling methods they shouldn't be). Being able to do this type
of thing is one of the more powerful/useful features of C++ IMO.
--Rob
On Feb 22, 2008, at 3:24 AM, Mike Abdullah wrote:
It's not possible to do this. ObjC will allow you to send any
message to any other object. The best you can do is not publicly
expose the method and that is exactly what the Cocoa framework
does. To be honest, trying to use C++ just for this seems a
waste of time; perhaps you should explain why you want to do
this? Is it to try and partition your code up, is this something
that really MUST stop, say, plugins from accessing the code?
Mike.
On 22 Feb 2008, at 11:00, Philip Bridson wrote:
How do I make a method private?
I have tried putting @private before the method that I want to
make private but the compiler flags a parse error. I read the
documentation and I can only find reference to private member
variables. I want to make sure that a method can only be
accessed via another method in the same class. Is this possible
in Objective-C or do I need to write this class in C++?
Many thanks.
Phil.
_______________________________________________
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/cocoadev%
40mikeabdullah.net
This email sent to [EMAIL PROTECTED]
_______________________________________________
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/petrock%40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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/jpavao-lists%
40sericaia.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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]
